Catching Common Exception Handling Mistakes

Microsoft provides excellent guidance for exceptions, but it's easy to forget and make some of these common exception handling mistakes. Below is a list of "must remember" exception handling guidance when programming in C# (although most of this is also applicable to other .NET languages.)

When to Catch Exceptions?

Only catch an exception when you understand exactly why it will be thrown and can recover from it.

If you follow this one rule, it will prevent many of the problems that you can get into when handling exceptions.  Most of the time, you can find a list of exceptions that a member will throw from the member's XML documentation. You can access this documentation via Intellisense or by hovering the mouse cursor over the member. For detailed documentation, you can often see a list of exceptions along with the specific condition that will throw the exception on the member's MSDN documentation page.

This may feel funny at first, but remember that exceptions aren't bad. Understanding when and why a specific exception will be thrown will create more stable and secure code. If your application crashes because of an unhandled exception, that's just a signal that you forgot to program for a specific condition. So, before typing “catch” answer both of these questions:

1. Do I know exactly why this exception is being thrown here?
2. Can I recover from this exception?

Do not catch System.Exception
You should never catch System.Exception (or System.SystemException,) unless you plan to log and immediately re-throw the exception. Because all managed exceptions ultimately inherit from System.Exception, you cannot possibly know exactly why the exception you’re catching is being thrown. You should always catch the most specific exception type that you can.

If you do succumb to the temptation of catching System.Exception and are able to repress the shame from such coding do be sure to use “catch(Exception) {…}” NOT “catch {…}”. A catch statement without an exception type will catch all exceptions, including non-CLS exceptions.

"throw;" != "throw err;"
If you catch an exception for logging or other reasons, but then need to re-throw the exception, ALWAYS use "throw;". "throw err;" will affect the stack trace making troubleshooting more difficult. Look at the following call stacks and sample code for an example of the problem that "throw err;" causes.

// With throw err;
//at MyApp.Program.Method1() in ...\Program.cs:line 29
//at MyApp.Program.Run() in ...\Program.cs:line 18
//at MyApp.Program.Main(String[] args) in ...\Program.cs:line 13

class Program
{
  static void Main(string[] args)
  {
    Program p = new Program();
    p.Run();
  }

  void Run()
  {
    this.Method1();
  }

  void Method1()
  {
    try { Method2(); } catch (Exception err) { throw err; }
  }

  void Method2()
  {
    try { Method3(); } catch (Exception err) { throw err; }
  }

  void Method3()
  {
    throw new InvalidOperationException();
  }
}

// With throw;
//at MyApp.Program.Method3() in ...\Program.cs:line 33
//at MyApp.Program.Method2() in ...\Program.cs:line 28
//at MyApp.Program.Method1() in ...\Program.cs:line 23
//at MyApp.Program.Run() in ...\Program.cs:line 18
//at MyApp.Program.Main(String[] args) in ...\Program.cs:line 13

class Program
{
  static void Main(string[] args)
  {
    Program p = new Program();
    p.Run();
  }

  void Run()
  {
    this.Method1();
  }

  void Method1()
  {
    try { Method2(); } catch (Exception) { throw; }
  }

  void Method2()
  {
    try { Method3(); } catch (Exception) { throw; }
  }

  void Method3()
  {
    throw new InvalidOperationException();
  }
}