Click here to Skip to main content
Click here to Skip to main content

Logging is the new Exception Swallowing

By , 4 May 2011
 

For a long time now, I've been stamping down hard on empty catch blocks in code, for obvious reasons. When I can dictate coding standards, that's pretty much top the list.

  1. Every 'catch' block must (at a minimum) log or throw.

    I now realize I made a mistake with this rule...it should be:

  2. Every 'catch' block must (at a minimum) throw or log.

    It's a subtle (the wording – not the formatting) difference in the way we need to think about this rule but it's one I think we don't think about enough.

For example, this is a common pattern of code that I'm seeing during Code Review sessions:

public bool PerformCriticalTask()
{
    try
    {
        CriticalFunctionalityTaskA();
        CriticalFunctionalityTaskB();
        CriticalFunctionalityTaskC();
        return true;
    }
    catch(Exception ex)
    {
        Logger.Log(ex);
    }
    return false;
}
  
public CriticalFunctionalityTaskA()
{
    try
    {
        //Do Important Stuff Here
    }
    catch(Exception ex)
    {
        Logger.Log(ex);
    }
}
  
public CriticalFunctionalityTaskB()
{
    try
    {
        //Do More Important Stuff Here
    }
    catch(Exception ex)
    {
        Logger.Log(ex);
    }
}
  
public CriticalFunctionalityTaskC()
{
    try
    {
        //Do The Most Important Stuff
    }
    catch(Exception ex)
    {
        Logger.Log(ex);
    }
}

It's pretty clear that this Catch/Log pattern has become a developer's default exception handling boiler plate code. It's adding no value and actually making the troubleshooting processes more complicated and time consuming. 

My response to this is simple… remove all exception handling!

In the vast majority of cases, if an exception is thrown, the application is already broken and letting it limp along is an act of cruelty. The application should handle these critical failures as exceptional and handle all of these events the same way in an application scoped way (Custom Error Page for Web Applications, etc.). By all means, log the exception at the application scope level, it will have actual diagnostic value there (complete stack trace, etc.).

Of course, there are exceptions to this policy such as when you can legitimately recover from the fault. But these cases are few and far between.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Martin Jarvis
Software Developer (Senior) Freestyle Interactive Ltd
United Kingdom United Kingdom
I'm a lead developer for Freestyle Interactive Ltd where we create many wonderful websites built on Microsofts ASP.Net and Ektron CMS.
 
I've been developing .Net applications (both Windows and Web) since 2002.
Follow on   Twitter

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
RantSwallowing, logging, rethrowing, and ignoring PinmemberSeth Morris10-May-11 10:36 

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.

Permalink | Advertise | Privacy | Mobile
Web03 | 2.6.130617.1 | Last Updated 4 May 2011
Article Copyright 2011 by Martin Jarvis
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid