Click here to Skip to main content
Click here to Skip to main content
Technical Blog

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
Follow on   Twitter   LinkedIn

Comments and Discussions

GeneralMy vote of 5 PinmemberJasmine25014-Mar-13 13:33 
GeneralRe: My vote of 5 PinmemberJasmine25014-Mar-13 13:34 
GeneralRe: My vote of 5 Pinmemberjgauffin4-Mar-13 23:19 
GeneralRe: My vote of 5 PinmemberJasmine25015-Mar-13 6:12 
GeneralMy vote of 5 PinmemberRobert 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 Pinmemberjahmani1-Mar-13 11:20 
QuestionGood article, but exceptions are all about how the solution should behave. Pinmemberegilagre3-Dec-12 3:39 
QuestionFinally Pinmemberpip0106-Nov-12 3:13 
AnswerRe: Finally Pinmemberjgauffin6-Nov-12 3:16 
GeneralRe: Finally Pinmemberpip0106-Nov-12 5:43 
GeneralRe: Finally Pinmemberjgauffin6-Nov-12 5:46 
GeneralRe: Finally Pinmemberpip0106-Nov-12 5:57 
GeneralRe: Finally PinmemberJasmine25014-Mar-13 9:48 
GeneralRe: Finally Pinmemberpip0105-Mar-13 0:14 
GeneralNice PinmemberZac Greve9-Sep-12 9:04 
GeneralTotally agree with you but... PinmemberLokanta_brahmachari18-Nov-10 4:56 
GeneralRe: Totally agree with you but... Pinmemberjgauffin20-Nov-10 10:37 
GeneralRe: Totally agree with you but... Pinmemberpip0106-Nov-12 5:39 
GeneralFor Capture information about exceptions without catching them Pinmembersupercat915-Nov-10 8:05 
GeneralRe: For Capture information about exceptions without catching them Pinmemberjgauffin15-Nov-10 22:40 
GeneralMy vote of 5 Pinmemberthatraja9-Nov-10 20:50 
GeneralGood article.... PinmemberGlimmerMan9-Nov-10 6:03 
Generalexcelent article PinmemberSplit_fire8-Nov-10 22:44 
General5-5 Pinmembererick.granados8-Nov-10 18:35 
GeneralGreat advice PinmemberCurtainDog8-Nov-10 13:39 
GeneralRe: Great advice Pinmemberjgauffin8-Nov-10 21:06 
GeneralRe: Great advice Pinmemberpip0106-Nov-12 5:47 
GeneralRe: Great advice PinmemberJasmine25014-Mar-13 9:52 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    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.150327.1 | Last Updated 1 Mar 2013
Article Copyright 2010 by jgauffin
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid