Do NOT Catch That Exception!

Ohhh, I’ve recently seen one to many applications where developers try to be safe by catching exceptions all over the place. It can be everything from a small simple method that doesn’t throw that many exceptions to a large method with multiple try/catch statements. Most of those catch blocks just log the exception and rethrow it.

Please do not catch that exception. Let it travel down the call stack. I promise you that you won’t regret it. You’ll get a warm and fuzzy feeling next time you’ll test your application. I promise you! Really!

Why? You’ll get a complete exception with all the details you need to fix the error. The problem with all of those try/catch blocks is they don’t help your application in any way. They just clutter up the code and your log files.

If you still want to catch exceptions: I’ll try to explain the way to do it.

Catching Exceptions in the Correct Way

Yeah. Proper exception handling can be something wonderful. You’ll smile every time you get an exception. First of all: Exceptions only happen when something exceptional occurs. Please have that in mind, because it helps you remember that you don’t need those try/catch block everywhere. That brings us to the golden rule about when to catch exceptions:

Only Catch Exceptions that You Can Handle to Rescue the Situation

You should only catch exceptions if you can deliver the result as promised by the method contract. For instance, if the return value from a method is an User object, you should only catch an exception if you in fact can return a User.

Anything else is not really exception handling but just diagnostics.

There are of course exceptions, namely two of them:

Do Not Let Layer Specific Exceptions Propagate Up the Call Stack

For instance, if the data layer fails and throws a SqlException (if you are using SQL Server), you should catch it and wrap it inside a more generic exception. For instance: Create a DataSourceException which could be used even if you switch data source from a database to a Web Service. You should of course add details to the exception such as the method in your data layer that failed (let’s say “SearchUsers”) and the arguments for that method. Do NOT forget to add the original exception as inner exception.

public class UserRepository : IUserRepository
{
    public IList<User> Search(string value)
    {
        try
        {
              return CreateConnectionAndACommandAndReturnAList(
                 "WHERE value=@value", Parameter.New("value", value));
        }
        catch (SqlException err)
        {
             var msg = String.Format(
                 "Ohh no!  Something failed when you tried to search after users" +
                 "with '{0}' as search string", value);
             throw new DataSourceException(msg, err);
        }
    }
}

Update 2013-03-01: I'm not following this rule any more. The only time I wrap exceptions is if I add more context information to help me prevent the exception in the future. It doesn't really matter if the data layer exception is passed up the call stack, since it won't be handled, but just logged in the top layer.

If you don't want to display data layer specific information to the user, then simply display something like "An unexpected error occurred" instead of showing exception information. The exception information doesn't really help your user either way.

Try/Catch All is OK in the Layer Closest to the User

Ok, so you have let the exceptions propagate through all your layers to the presentation layer (winforms/ASP.NET, etc.). Fine. Go ahead, give the user some fancy error pages. Also log those errors. But just don’t log them. Notify a support team. Send an email to the project lead.

When Everything Else Fails

Are you not sure that your new exception policy will catch all of those exceptions? Is it scary? Then I got the solution for YOU!

• ASP.NET: Implement Aplication_OnError(object source, EventArgs e) in your global.asa. It will be called for all unhandled exceptions.
• Winforms: Subscribe on Application.ThreadException
• Winservices/console apps: Subscribe on AppDomain.CurrentDomain.UnhandledException. The problem with this event is that it will still terminate the application. But there’s a way around that too
• WCF: Implement IErrorHandler and log the exceptions in it (added 2013-03-01)
• ASMX: Create a custom Soap Extension (added 2013-03-01)

In the next blog post, I’ll discuss common mistakes in those catch blocks and how your tailor made exceptions should look like.