More Elegant Exception Handling Than Multiple Catch Blocks?

Using C#, is there a better way to handle multiple types of exceptions rather than a bunch of ugly catch blocks?

What is considered best practice for this type of situation?

For example:

try
{
    // Many types of exceptions can be thrown
}
catch (CustomException ce)
{
    ...
}
catch (AnotherCustomException ace)
{
    ...
}
catch (Exception ex)
{
    ...
}

In my opinion, a bunch of "ugly" catch blocks IS the best way to handle that situation.

The reason I prefer this is that it is very explicit. You are explicitly stating which exceptions you want to handle, and how they should be handled. Other forms of trying to merge handling into more concise forms lose readability in most cases.

My advice would be to stick to this, and handle the exceptions you wish to handle explicitly, each in their own catch block.

I agree with Reed: this is the best approach.

I would add these comments:

Only catch something you're going to do something about. If you can't fix the problem, there's no point in catching a specific exception.

Don't overdo use of catch blocks. In many cases where you can't resolve the exception, it's best to just let the exception bubble up to a central point (such as Page_Error) and catch it there. Then, you log the exception and display a message to the user.

About the only other thing you can do is emulate VB.NET's exception filters:

try {
    DoSomething();
} catch (Exception e) {
    if (!ex is CustomException && !ex is AnotherCustomException) {
       throw;
    }
    // handle
}

Sometimes this is better, sometimes not. I'd mainly use it if there was some common logic I wanted in the handler, but the exceptions don't share a base type.

Unfortunately, C# does not have user exception filters like VB.NET, so you're limited to:

1. Catching a common ancestor to all exceptions. This may or may not be what you want, because there may be other descendant exception types that you do not want to catch.
2. Moving the exception handling logic into another method and calling that from each handler.
3. Repeating the exception logic for each handler.
4. Moving the exception handling logic into a language that supports filters, such as VB.NET.

If you need to write a really big ammount of code like this I would suggest checking some AOP framework. I personally use PostSharp. Then you could hide all exception handling code into aspects.

You should check out the Enterprise Library Exception Handling block. It allows for much more fine grain control over exceptions through policies (wrapping policies, propagation policies, replacement policies, logging policies, etc.) You can use it to standardize the way you code an exception block and use configuration to handle precisely what happens with a particular type of exception.

Is this way not good?

If you want to handle only one exception:

try
{
    // Many types of exceptions can be thrown
}
catch (TheExceptionIWantToHandle ex)
{
    // handle it
}
catch (Exception ex)
{
    // suppress all other exceptions
}

If you want to handle all exceptions except one:

try
{
    // Many types of exceptions can be thrown
}
catch (TheExceptionIDoNotWantToHandle ex)
{
    // suppress all other exceptions
}
catch (Exception ex)
{
    // handle it
}

good, not good?

Catch only what you need to resolve specifically and leave

catch(Exception e)
{
}

for everything else (or skip it and give this exceptions to the stack)