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();
  }
}

Event handlers are a common cause of memory leaks in managed applications. It’s so easy to register an event handler, that sometimes we can forget what’s actually happening. There are three parties involved in eventing: the event source, a delegate, and the event sink.

The event source is the object that publishes notifications via an event. The event sink is the object that is interested in those notifications and knows how to respond to the event. The delegate is the object that enables the event source to communicate with the event sink.

Looking at the System.Delegateclass, we see that it has two properties: Target and Method. Target contains a reference to the event sink object and Method contains a MethodInfo object used to invoke the event handler method on the event sink object. When you use the C# statement eventSource.SomeEvent += new EventHandler(eventSink.SomeEventHandler); you are creating a new delegate with a reference to your event sink object and adding a reference to the delegate class to the event source object. The references look like this: event source > delegate > event sink.

The effect of this isn’t very visible when the lifetime of the event source and event sink are similar. However, when the event source lives much longer, say for the lifetime of the application, and the event sink only has a short lifetime, you can quickly leak memory because the event source will never release it’s reference to the event sink.

Consider this example

The output for this is:

How to avoid this?
You need to keep this subtle problem in mind when designing your classes. To prevent these types of memory leaks, you’ll need to design mechanisms into your object’s lifecycle so that it can detach it’s event handlers. Detaching an event handler is as simple as using the –= operator. The difficult part is knowing when to detach. You can use the IDisposable pattern or expose a CleanUp() method or add lifecycle events to trigger the detach.

Thank you to everyone who came to the Springfield .NET Users group meeting last Tuesday and a special thank you to PaperWise for hosting the meeting. I hope everyone found the information on WCF useful; I appreciate your questions and feedback. As promised, I'm posting my presentation slides and source code. Enjoy!

WCFPresentation_20090922.zip (949.00 kb)