54

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) { ... }
Improve this question
0

8 Answers 8

Reset to default
77

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Do you see any downsides to Mark Brackett's filter solution?
@TrueWill: IMO, it just reduces maintainability, without really adding a lot of functionality. That being said, it's not horrible - just non-obvious.
23

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.

Improve this answer

2 Comments

+1 - Great point about not catching "extra" exceptions. I was trying to mention that (in my saying that it causes you to be explicit about what you want to handle) - but you're right - you usually shouldn't handle everything, unless you're going to handle it in a meaningful way.
Also +1. I want to add that sometimes developers add catch blocks to every method so they can trace what method actually threw the exception. That's what the stack trace is for!
16

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.

Improve this answer

2 Comments

Negative logic makes my left eye feel funny. In a case like this, how about if(!(ex is CustomException || ex is AnotherCustomException)) ?
That's still negative logic, you just ran De Morgan on it. Readability is arguably bad either way. I would do something like if (ex is CustomException || ex is AnotherCustomException) { /*handle*/ } else { throw; } or bool canHandle = ex is CustomException || ex is AnotherCustomException; if (!canHandle) throw; /* handle */
10

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.
Improve this answer

1 Comment

As of the C# 6.0 language specification (new in .NET 4.6 / Visual Studio 2015), C# supports "Exception Filters" using the syntax: catch (Exception ex) if (ex.Message.Contains("Fatal")).
5

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.

Improve this answer

Comments

2

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.

Improve this answer

Comments

0

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?

Improve this answer

1 Comment

Not good, in general. Don't suppress exceptions without logging them in some way. Otherwise, you could be hiding important information. Also, IMHO there is very little reason to ever do "catch (exception ex)", unless you're going to log it, or wrap it, and then use the "throw;" statement to allow it to propagate.
-6

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)

Improve this answer

2 Comments

Won't this swallow the exception whole, which is almost always a bad idea?
Yes, this is an AWFUL piece of code, as-is. I think Mash was implying you throw in there...either that or he was drunk.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.