Examine an Exception in a Catch() Block

0 comments suggest edit

Found a useful nugget in Richter’s recent CLR via C# book I want to share with you. But first some background.

Sometimes when I write a catch block, I don’t really have any plans for the caught exception. The following is a contrived example that is somewhat realistic.

try
{
    DoSomething();
}
catch(System.SomeException)
{
    DoSomethingElse();
    throw;
}

In the above code, I only want DoSomethingElse() to execute if DoSomething() throws an exception of type SomeException. I can’t put DoSomethingElse() in a finally block because then it would always get called and not just when the exception is thrown. I don’t need to do anything with SomeException because I am propagating it up the callstack via the throw keyword to let some other method handle it.

But now, as I am stepping through the code in the debugger, I may actually want to examine SomeException when the debugger reaches the line DoSomethingElse(). Typically I would have to rewrite the code like so:

try
{
    DoSomething();
}
catch(System.FormatException e)
{
    DoSomethingElse();
    throw;
}

Just so I can examine the exception now stored in the variable e. This is plain dumb and Richter points out why in a little tip in his book. You can use the debugger variable $exception provided by the Visual Studio.NET Debugger to examine the exception in a catch block. I wish I had known about this a while ago.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.

Comments

avatar

6 responses

  1. Avatar for Cullen Waters
    Cullen Waters June 7th, 2006

    Another benefit of using $exception is that putting in the System.FormatException e, and then not using the e variable results in a compiler warning.
    Good tip, thanks.

  2. Avatar for Luke
    Luke June 7th, 2006

    Cool, thanks for the tip :)
    I'm mainly a Java programmer, and I habitually use e.printStackTrace() in all my catch blocks. Sometimes this helps me to see what is going on without even launching debugger.
    Once the code is tested and ready for production, I do a quick search and replace to comment out all the printStackTrace calls.

  3. Avatar for Bill Pierce
    Bill Pierce June 7th, 2006

    Phil,
    Great blog (regular reader). Oren just posted something you might find useful, might be 2.0 only. Would allow you to easily DoSomethingElse() whenver an exception is thrown, similar to the way the 'using' statement will call Dispose() for you.
    http://www.ayende.com/Blog/...
    -Bill

  4. Avatar for drew
    drew June 11th, 2006

    not sure I get it.. I tried your
    catch(System.Exception) {
    String foo = ""; //[1]
    }
    and at the [2] click SHift+F9 and paste "$exception" in the quick watch. It says
    "identifier '$exception' out of scope".
    I'm using VS2002 - could it matter?

  5. Avatar for Steve Crane
    Steve Crane June 20th, 2006

    Thanks for this. I have been wondering how to suppress the warnings about unreferenced variables, never thinking that the C# Reference and all the books I've looked at would neglect to mention that the variable name in a specific exception catch clause is optional. It takes a visit to the language specification document to find this out.

  6. Avatar for James Gregory
    James Gregory June 21st, 2006

    I'd usually end up adding the variable name temporarily, checking the exception with the debugger, then reverting the code.
    This way is so much better! Thanks.