As we all know C# provides for relatively elegant handling of errors with its try{} catch{} finally {} construct.

There are a couple of gotchas such as ThreadExceptions which bypass this stack and can only be caught at application level but for the most part it works ok.

However, there is one bug bear that drives me nuts, nuts enough that I have to write about it.

Catching multiple exception types

To catch multiple types of exception coming out of a block of code we are forced to write multiple catch() blocks, one for each type of exception.

If it makes sense from an application perspective to treat these differently then no problem, however, if we want to catch a lot of different exception types and perform some relatively simple logic on them (such as logging and re-throwing) it can be really irritating (not to mention buggy and hard to read) to maintain a long list of blocks.

Sure, we can factor out our exception handling into its own method, but this breaks the readability of the code and still requires a long list of “catch(…) {HandleError();}” statements which is a pain.

Wouldn’t it be nice if instead we could use syntax more like the using statement?

catch(ArgumentException)
catch(OutOfMemoryException)
catch(UnathorisedAccessException)
catch(CustomException)
{
    // handle error here
}

Now I realise that this has a problem, kind of a big one – what about the error object?

Well, that brings me first to another point… why do we always have to name our error object ex?

catch(Exception ex){}

Since we can only ever have a single error object inside a given catch block couldn’t we do something more like the set{} accessors? I.e. automatically name the object “value”?

e.g.

catch(ArgumentException)
{
    var msg = value.Message;
    // handle error here
}

Well, yes and no. I mean it looks nice and I have no doubt it would function… but unfortunately we can nest try-catch blocks within each other… so we would get name clashes (which instance of “value” are we talking about…).

Should we ever nest try-catch blocks within a catch block? I can’t say I ever have… I would argue that if error handling gets that complex it should be moved out to its own method. Unfortunately someone somewhere has probably done this so introducing this automated error handling would be a breaking change 🙁

Assuming such a change was possible then we could handle the multiple exception types realtively nicely by simply having the type of ‘value’ be the base type Exception. Why is this valid? Because by catching multiple exception types in a single handler we have already declared that we do not have any interest in their specific contents… so being able to get the basic data should be more than enough. 

catch(ArgumentException)
catch(OutOfMemoryException)
catch(UnathorisedAccessException)
catch(CustomException)
{
    log(value.Message);
    Application.Exit();
}

Sadly this is all a pipe dream, but I’d love to hear your thoughts on it… especially if you are a frequent user of nested catch blocks.

Update

I thought about this some more and came up with another syntax which might work and which perhaps could be done without making it a breaking change:

catch(ArgumentException,
     OutOfMemoryException,
     UnathorisedAccessException,
     CustomException) as ex
{
    log(ex.Message);
    Application.Exit();
}

Since we currently can’t use commas in the catch() part by introducing a comma we notate instantly that we are using the new syntax, we can list as many types as needed with minimal effort, and we can re-use (read abuse) the ‘as’ keyword to name the resulting object.

In this way we can have everything we want without breaking existing code… always a bonus 🙂

Connect

Turns out I’m not the only user with this desire… I found this Microsoft Connect sugestion on the same topic 🙂

see also