Click here to Skip to main content
12,068,508 members (72,433 online)
Click here to Skip to main content
Add your own
alternative version


44 bookmarked

Do NOT catch that exception!

, 1 Mar 2013 LGPL3
Rate this:
Please Sign up or sign in to vote.
Ohhh, I've recently seen one to many application where the 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 jus

Ohhh, I’ve recently seen one to many application where the 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 logs 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 doesn’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 happens 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)
              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/ 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? The 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.


This article, along with any associated source code and files, is licensed under The GNU Lesser General Public License (LGPLv3)


About the Author

Founder Gauffin Interactive AB
Sweden Sweden
Founder of OneTrueError, a .NET service which captures, analyzes and provide possible solutions for exceptions.

blog | twitter

You may also be interested in...

Comments and Discussions

GeneralMy vote of 5 Pin
Jasmine25014-Mar-13 13:33
memberJasmine25014-Mar-13 13:33 
GeneralRe: My vote of 5 Pin
Jasmine25014-Mar-13 13:34
memberJasmine25014-Mar-13 13:34 
GeneralRe: My vote of 5 Pin
jgauffin4-Mar-13 23:19
memberjgauffin4-Mar-13 23:19 
GeneralRe: My vote of 5 Pin
Jasmine25015-Mar-13 6:12
memberJasmine25015-Mar-13 6:12 
GeneralMy vote of 5 Pin
Robert Hoffmann2-Mar-13 5:47
memberRobert Hoffmann2-Mar-13 5:47 
Absolutely don't catch it ..if there is an exception then someone should be fixing it and not wrapping it up and stashing it away. If one does need to catch, then the exception should at least be forwarded to a easily accessible log of some type ..with preference one that is queryable or that sends out notifications.

Personally i switched to using healthmonitoring extensively a few years back are a pain, but once correctly configured it rocks. Even more since i have a custom web based backoffice slapped on top of it, and even propagate jquery, ajax, and window.onerror events back to the server via ajax methods

Some links and code if you are interested:
GeneralMy vote of 5 Pin
jahmani1-Mar-13 11:20
memberjahmani1-Mar-13 11:20 
QuestionGood article, but exceptions are all about how the solution should behave. Pin
egilagre3-Dec-12 3:39
memberegilagre3-Dec-12 3:39 
QuestionFinally Pin
pip0106-Nov-12 3:13
memberpip0106-Nov-12 3:13 
AnswerRe: Finally Pin
jgauffin6-Nov-12 3:16
memberjgauffin6-Nov-12 3:16 
GeneralRe: Finally Pin
pip0106-Nov-12 5:43
memberpip0106-Nov-12 5:43 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.160208.1 | Last Updated 1 Mar 2013
Article Copyright 2010 by jgauffin
Everything else Copyright © CodeProject, 1999-2016
Layout: fixed | fluid