.NET: Avoidance of custom exceptions by utilising existing types, but which?

Posted by Mr. Disappointment on Stack Overflow See other posts from Stack Overflow or by Mr. Disappointment
Published on 2011-03-18T16:00:22Z Indexed on 2011/03/18 16:10 UTC
Read the original article Hit count: 294

Filed under:
|
|
|

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?

© Stack Overflow or respective owner

Related posts about c#

Related posts about .NET