Why catch and rethrow Exception in C#?

Question

Hi,

Folks, forgive me, I'm pretty much a raw prawn when it comes to C#, and .NET generally... though I've been a professional programmer for 10 years.

I'm looking at this article: http://www.codeproject.com/KB/cs/datatransferobject.aspx on Serializable DTO's.

The article includes this piece of code:

public static string SerializeDTO(DTO dto) {
    try {
        XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
        StringWriter sWriter = new StringWriter();
        xmlSer.Serialize(sWriter, dto);
        return sWriter.ToString();
    } catch(Exception ex) {
        throw ex;
    }
}

The rest of the article looks sane and reasonable (to a noob), but that try-catch-throw throws a WtfException... Isn't this exactly equivalent to not handling exceptions at all?

Ergo:

public static string SerializeDTO(DTO dto) {
    XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
    StringWriter sWriter = new StringWriter();
    xmlSer.Serialize(sWriter, dto);
    return sWriter.ToString();
}

Or am I missing something fundamental about error handling in C#... It's pretty much the same as Java (minus checked exceptions), isn't it? ... i.e they both refined C++.

I did search: Both SO and google, and failed to find an "authorative answer" to exactly this question... though this thread seems to support my contention that try-catch-throw is-a no-op.

Cheers all. Thanx for your time.

---

EDIT:

Just to summarise for anyone who finds this thread in future...

DO NOT

try {
  // do stuff that might throw an exception
} catch (Exception e) {
  throw e; // this destroys the strack trace information!
}

The stack trace information can be crucial to identifying the root cause of the problem!

DO

try {
  // do stuff that might throw an exception
} catch (SqlException e) {
  // log it
  if (e.ErrorCode != NO_ROW_ERROR) { // filter out NoDataFound.
    // do special cleanup, like maybe closing the "dirty" database connection.
    throw; // this preserves the stack trace
  }
} catch (IOException e) {
  // log it
  throw;
} catch (Exception e) {
  // log it
  throw new DAOException("Excrement occurred", e); // wrapped & chained exceptions (just like java).
} finally {
  // normal clean goes here (like closing open files).
}

Catch the more specific exceptions before the less specific ones (just like Java).

Thank you all for your time.

Cheers all. Keith.

---

References:

• MSDN - Exception Handling
• MSDN - try-catch (C# Reference)

Answer 1

You don't want to throw ex - as this will lose the call stack.

http://msdn.microsoft.com/en-us/library/ms229005.aspx

And yes, the try...catch is doing nothing useful (apart from lose the call stack - so it's actually worse - unless for some reason you didn't want to expose this information)

Answer 2

First; the way that the code in the article does it is evil. throw ex will reset the call stack in the exception to the point where this throw statement is; losing the information about where the exception actually was created.

Second, if you just catch and re-throw like that, I see no added value, the code example above would be just as good (or, given the throw ex bit, even better) without the try-catch.

However, there are cases where you might want to catch and rethrow an exception. Logging could be one of them:

try 
{
    // code that may throw exceptions    
}
catch(Exception ex) 
{
    // add error logging here
    throw;
}

Answer 3

A valid reason for rethrowing exceptions can be that you want to add information to the exception, or perhaps wrap the original exception in one of your own making:

public static string SerializeDTO(DTO dto) {
  try {
      XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
      StringWriter sWriter = new StringWriter();
      xmlSer.Serialize(sWriter, dto);
      return sWriter.ToString();
  }
  catch(Exception ex) {
    string message = 
      String.Format("Something went wrong serializing DTO {0}", DTO);
    throw new MyLibraryException(message, ex);
  }
}

Answer 4

Don't do this,

try 
{
...
}
catch(Exception ex)
{
   throw ex;
}

You'll lose the stack trace information...

Either do,

try { ... }
catch { throw; }

OR

try { ... }
catch (Exception ex)
{
    throw new Exception("My Custom Error Message", ex);
}

One of the reason you might want to rethrow is if your handling different exceptions e.g.

try
{
   ...
}
catch(SQLException sex)
{
   //Do Custom Logging 
   //Don't throw exception - swallow it here
}
catch(OtherException oex)
{
   //Do something else
   throw new WrappedException("Other Exception occured");
}
catch
{
   System.Diagnostics.Debug.WriteLine("Eeep! an error, not to worry, will be handled higher up the call stack");
   throw; //Chuck everything else back up the stack
}

Answer 5

it depends what you are doing in the catch block, and if you are wanting to pass the error on to the calling code or not.

you might say Catch io.FileNotFoundExeption ex and then use an alternative file path or some such, but still throw the error on.

Also doing Throw instead of Throw Ex allows you to keep the full stack trace. Throw ex restarts the stack trace from the throw statement (hope that makes sense)

Answer 6

Isn't this exactly equivalent to not handling exceptions at all?

Not exactly, it isn't the same. It resets the exception's stacktrace. Though I agree that this probably is a mistake, and thus an example of bad code.

Answer 7

In the example in the code you have posted there is, in fact, no point in catching the exception as there is nothing done on the catch it is just re-thown, in fact it does more harm than good as the call stack is lost.

You would, however catch an exception to do some logic (for example closing sql connection of file lock, or just some logging) in the event of an exception the throw it back to the calling code to deal with. This would be more common in a business layer than front end code as you may want the coder implementing your business layer to handle the exception.

To re-iterate though the There is NO point in catching the exception in the example you posted. DON'T do it like that!

Answer 8

C# doesn't support CIL "filtered exceptions", which VB does, so in C# one reason for re-throwing an exception is that you don't have enough information at the time of catch() to determine whether you wanted to actually catch the exception.

For example, in VB you can do

Try
 ..
Catch Ex As MyException When Ex.ErrorCode = 123
 .. 
End Try

...which would not handle MyExceptions with different ErrorCode values. In C#, you would have to catch and re-throw the MyException if the ErrorCode was not 123:

try {
 ..
}
catch(MyException ex) {
 if (ex.ErrorCode != 123) throw;
 ..
}

Answer 9

One possible reason to catch-throw is to disable any exception filters deeper up the stack from filtering down (random old link). But of course, if that was the intention, there would be a comment there saying so.

Answer 10

Sorry, but many examples as "improved design" still smell horribly or can be extremely misleading. Having try { } catch { log; throw } is just utterly pointless. Exception logging should be done in central place inside the application. exceptions bubble up the stacktrace anyway, why not log them somewhere up and close to the borders of the system?

Caution should be used when you serialize your context (i.e. DTO in one given example) just into the log message. It can easily contain sensitive information one might not want to reach the hands of all the people who can access the log files. And if you don't add any new information to the exception, I really don't see the point of exception wrapping. Good old Java has some point for that, it requires caller to know what kind of exceptions one should expect then calling the code. Since you don't have this in .NET, wrapping doesn't do any good on at least 80% of the cases I've seen.

Answer 11

My main reason for having code like:

try
{
  //Some code
}
catch ( Exception e )
{
  throw;
}

Is so i can have a breakpoint in the catch, that has an instantiated Exception object. I do this a lot while developing/debugging. Of course the compiler gives me warning on all the unused e's, and ideally they should be removed before a release build.

They are nice during debugging though.

Answer 12

In addition to what the others have said, see my answer to a related question which shows that catching and rethrowing is not a no-op (it's in VB, but some of the code could be C# invoked from VB).