Best practices for catching and re-throwing NET exceptions

Question

What are the best practices to consider when catching exceptions and re-throwing them  I want to make sure that the Exception object s InnerException and stack trace are preserved  Is there a difference between the following code blocks in the way they handle this   try         some code   catch  Exception ex        throw ex      Vs   try         some code   catch       throw

User · Accepted Answer

The way to preserve the stack trace is through the use of the throw; This is valid as well

try {
  // something that bombs here
} catch (Exception ex)
{
    throw;
}

throw ex; is basically like throwing an exception from that point, so the stack trace would only go to where you are issuing the throw ex; statement.

Mike is also correct, assuming the exception allows you to pass an exception (which is recommended).

Karl Seguin has a great write up on exception handling in his foundations of programming e-book as well, which is a great read.

Edit: Working link to Foundations of Programming pdf. Just search the text for "exception".

User · Answer

If you throw a new exception with the initial exception you will preserve the initial stack trace too    try     catch Exception ex        throw new MoreDescriptiveException  here is what was happening   ex

User · Answer

I would definitely use   try         some code   catch         you should totally do something here  but feel free to rethrow       if you need to send the exception up the stack      throw      That will preserve your stack

User · Answer

Nobody has explained the difference between ExceptionDispatchInfo Capture  ex   Throw   and a plain throw  so here it is  However  some people have noticed the problem with throw   The complete way to rethrow a caught exception is to use ExceptionDispatchInfo Capture  ex   Throw    only available from  Net 4 5    Below there are the cases necessary to test this   1   void CallingMethod           try               throw new Exception   TEST                 catch                 throw            2   void CallingMethod         try               throw new Exception   TEST               catch  Exception ex                 ExceptionDispatchInfo Capture  ex   Throw            throw     So the compiler doesn t complain about methods which don t either return or throw            3   void CallingMethod         try               throw new Exception   TEST               catch               throw            4   void CallingMethod         try               throw new Exception   TEST               catch  Exception ex                 throw new Exception   RETHROW   ex              Case 1 and case 2 will give you a stack trace where the source code line number for the CallingMethod method is the line number of the throw new Exception   TEST    line   However  case 3 will give you a stack trace where the source code line number for the CallingMethod method is the line number of the throw call  This means that if the throw new Exception   TEST    line is surrounded by other operations  you have no idea at which line number the exception was actually thrown   Case 4 is similar with case 2 because the line number of the original exception is preserved  but is not a real rethrow because it changes the type of the original exception

User · Answer

When you throw ex  you re essentially throwing a new exception  and will miss out on the original stack trace information   throw is the preferred method

User · Answer

Actually  there are some situations which the throw statment will not preserve the StackTrace information  For example  in the code below   try     int i   0    int j   12   i     Line 47   int k   j   1    catch        do something            throw     Line 54     The StackTrace will indicate that line 54 raised the exception  although it was raised at line 47   Unhandled Exception  System DivideByZeroException  Attempted to divide by zero     at Program WithThrowIncomplete   in Program cs line 54    at Program Main String   args  in Program cs line 106   In situations like the one described above  there are two options to preseve the original StackTrace   Calling the Exception InternalPreserveStackTrace  As it is a private method  it has to be invoked by using reflection    private static void PreserveStackTrace Exception exception      MethodInfo preserveStackTrace   typeof Exception  GetMethod  InternalPreserveStackTrace       BindingFlags Instance   BindingFlags NonPublic     preserveStackTrace Invoke exception  null       I has a disadvantage of relying on a private method to preserve the StackTrace information  It can be changed in future versions of  NET Framework  The code example above and proposed solution below was extracted from Fabrice MARGUERIE weblog   Calling Exception SetObjectData  The technique below was suggested by Anton Tykhyy as answer to In C   how can I rethrow InnerException without losing stack trace question   static void PreserveStackTrace  Exception e        var ctx   new StreamingContext   StreamingContextStates CrossAppDomain       var mgr   new ObjectManager      null  ctx       var si    new SerializationInfo  e GetType     new FormatterConverter           e GetObjectData     si  ctx        mgr RegisterObject  e  1  si       prepare for SetObjectData    mgr DoFixups                       ObjectManager calls SetObjectData        voila  e is unmodified save for  remoteStackTraceString       Although  it has the advantage of relying in public methods only it also depends on the following exception constructor  which some exceptions developed by 3rd parties do not implement    protected Exception      SerializationInfo info      StreamingContext context     In my situation  I had to choose the first approach  because the exceptions raised by a 3rd-party library I was using didn t implement this constructor

User · Answer

A few people actually missed a very important point -  throw  and  throw ex  may do the same thing but they don t give you a crucial piece of imformation which is the line where the exception happened   Consider the following code   static void Main string   args        try               TestMe              catch  Exception ex                string ss   ex ToString             static void TestMe         try                 here s some code that will generate an exception - line  17           catch  Exception ex                  throw new ApplicationException ex ToString             throw ex     line  22           When you do either a  throw  or  throw ex  you get the stack trace but the line  is going to be  22 so you can t figure out which line exactly was throwing the exception  unless you have only 1 or few lines of code in the try block   To get the expected line  17 in your exception you ll have to throw a new exception with the original exception stack trace

User · Answer

You should always use  throw   to rethrow the exceptions in  NET   Refer this  http   weblogs asp net bhouse archive 2004 11 30 272297 aspx  Basically MSIL  CIL  has two instructions -  throw  and  rethrow     C  s  throw ex   gets compiled into MSIL s  throw    C  s  throw   - into MSIL  rethrow     Basically I can see the reason why  throw ex  overrides the stack trace

User · Answer

FYI I just tested this and the stack trace reported by  throw   is not an entirely correct stack trace  Example       private void foo                 try                       bar 3               bar 2               bar 1               bar 0                     catch DivideByZeroException                          log message and rethrow                throw                       private void bar int b                int a   1          int c   a b      Generate divide by zero exception          The stack trace points to the origin of the exception correctly  reported line number  but the line number reported for foo   is the line of the throw  statement  hence you cannot tell which of the calls to bar   caused the exception

User · Answer

The rule of thumb is to avoid Catching and Throwing the basic Exception object  This forces you to be a little smarter about exceptions  in other words you should have an explicit catch for a SqlException so that your handling code doesn t do something wrong with a NullReferenceException   In the real world though  catching and logging the base exception is also a good practice  but don t forget to walk the whole thing to get any InnerExceptions it might have

User · Answer

You may also use   try      Dangerous code   finally      clean up  or do nothing     And any exceptions thrown will bubble up to the next level that handles them

[c#] Best practices for catching and re-throwing .NET exceptions

Examples related to c#

Examples related to .net

Examples related to exception-handling

Examples related to rethrow