.NET: Avoidance of custom exceptions by utilising existing types, but which?
- by Mr. Disappointment
Consider the following code (ASP.NET/C#):
private void Application_Start(object sender, EventArgs e)
{
if (!SetupHelper.SetUp())
{
throw new ShitHitFanException();
}
}
I've never been too hesitant to simply roll my own exception type, basically because I have found (bad practice, or not) that mostly a reasonable descriptive type name gives us enough as developers to go by in order to know what happened and why something might have happened. Sometimes the existing .NET exception types even accommodate these needs - regardless of the message.
In this particular scenario, for demonstration purposes only, the application should die a horrible, disgraceful death should SetUp not complete properly (as dictated by its return value), but I can't find an already existing exception type in .NET which would seem to suffice; though, I'm sure one will be there and I simply don't know about it.
Brad Abrams posted this article that lists some of the available exception types. I say some because the article is from 2005, and, although I try to keep up to date, it's a more than plausible assumption that more have been added to future framework versions that I am still unaware of.
Of course, Visual Studio gives you a nicely formatted, scrollable list of exceptions via Intellisense - but even on analysing those, I find none which would seem to suffice for this situation...
ApplicationException: ...when a
non-fatal application error occurs
The name seems reasonable, but the
error is very definitely fatal - the
app is dead.
ExecutionEngineException: ...when
there is an internal error in the
execution engine of the CLR
Again, sounds reasonable,
superficially; but this has a very
definite purpose and to help me out
here certainly isn't it.
HttpApplicationException: ...when
there is an error processing an HTTP
request
Well, we're running an ASP.NET
application! But we're also just
pulling at straws here.
InvalidOperationException: ...when a
call is invalid for the current state
of an instance
This isn't right but I'm adding it to
the list of 'possible should you put a
gun to my head, yes'.
OperationCanceledException: ...upon
cancellation of an operation the
thread was executing
Maybe I wouldn't feel so bad using
this one, but I'd still be hijacking
the damn thing with little right.
You might even ask why on earth I would want to raise an exception here but the idea is to find out that if I were to do so then do you know of an appropriate exception for such a scenario? And basically, to what extent can we piggy-back on .NET while keeping in line with rationality?
