I am now a published DevSource article author. :)

Well actually, Bob Reselman (aka Mr. Coding Slave) did nearly all of the writing. I merely provided technical editing and proofing along with clarifying some sections. In return, he graciously gave me a byline.

The article is a beginners guide to exceptions.NET. and Bob did a bang-up job especially given the circumstances. He writes in a very approachable manner.

Hopefully, we can follow-up with a more in-depth version to take beginners to the next level in understanding best practices. One thing I wish we had discussed in the article is the guidelines around re-throwing exceptions. For example, I’ve seen many beginning developers make the following mistake…

public void SomeMethod()
{
  try
  {
    SomeOtherMethod(null);
  }
  catch(ArgumentNullException e)
  {
    //Code here to do something

    throw e; //Bad!
  }

The problem with this approach is the code in the catch clause is throwing the exception it caught. The runtime generates a stack trace from the point at which an exception is thrown. In this case, the stack trace will show the stack starting from the line throw e and not the line of code where the exception actually occurred.

If this is confusing, consider that the runtime doesn’t exactly distinguish between these three cases…

Exception exc = new Exception();

throw exc;

throw new Exception();

throw SomeExceptionBuilderFunction();

If you really intend to rethrow an exception without wrapping it in another exception, then the proper syntax is to use the throw keyword without specifying an exception. The original exception will propagate up with its stack trace intact.

public void SomeMethod()
{
  try
  {
    SomeOtherMethod(null);
  }
  catch(ArgumentNullException e)
  {
    //Code here to do something
 
    throw; //Better!
  }
}

However, even this can be improved on depending on why we are catching the exception in the first place. If we are performing cleanup code in the catch clause, it would be better to move that code to the finally block and not even catch the exception in the first place.

Also, using the throw syntax as illustrated above can affect the debuggability of a system. Christopher Blumme points this out in his annotation in the book Framework Design Guidelines (highly recommended) where he notes that attaching a debugger works by detecting exceptions that are left unhandled. If there is a series of catch and throw segments up the stack, the debugger might only attach to the last segment, far away from the actual point at which the exception occurred.

public void SomeMethod()
{
  try
  {
    SomeOtherMethod(null);
  }
  finally
  {
    CleanUp(); //Possibly even better
  }
}

Bob and I plan to follow-up with hopefully more articles covering exceptions. This is just a start.