When the first beta of the .Net framework was released one of the best features I thought was that the Exception.ToString() method shows you the stack trace from the place where the exception is thrown to where it is caught. Stack traces are your best friend when finding the cause of an unexpected exception. Back in the VB 6 time we spent a lot of effort harvesting this information ourselves.
This is why I get really upset when someone screws up the stack trace information by doing something like the following.
try
{
// method call that might throw an exception at some deeper level
some.Method();
}
catch (Exception ex)
{
// some code to figure out what to do with the exception (maybe logging or whatever)
// hmm in this case we do not really handle this exception after all, lets re-throw
throw ex;
}
What is wrong with this code? It is the 'ex' behind the throw. When you re-throw an exception this way the stack trace information in the Exception object is cleared and it will appear to who ever catches it at a higher level as if the exception originated from the location where it is re-thrown, thereby loosing valuable information about the location where the exception really occurred.
Inside a catch block you are allowed to use trow; (without an exception). The C# reference doesn't say very much about this, except that it is used when re-throwing the current exception object in a catch clause. Sounds like it is pretty much the same as when you do explicitly throw the exception you just caught as in the code example.
There is however a big difference that is not directly clear from the documentation. When you use throw without an exception you are actually saying "lets pretend I never caught this exception". This causes the Exception to be thrown further up while preserving the whole stack trace from the original throw to the next catch up the call stack.
Now pretty please, with sugar on top, use throw; instead of throw ex; inside a catch block, and leave my stack trace alone!
No comments:
Post a Comment