Catch Exception treatment

Question

What\'s the difference between using

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

and using

catch   //  might include  (Exc         


        

Answer 1

The first one resets the stack trace property in the thrown exception

Answer 2

Well, the first one will erase the stack trace, and replace it with where your throw is. The second one will throw the exception without altering the stack trace.

Also, "catch" will catch ANYTHING that is thrown, whether it is an exception or not.

The 2nd one is actually the equivalent of doing "catch(object)".

Answer 3

As far as I know, it's the same thing (using Exception.. because all the exceptions derive from that class). It becomes different when you catch only a child of Exception... or when you have several "catch" catching different children. It could also be that you catch Exception, modify the message, and throw it back out.

Answer 4

throw ex re-throws the exception object from that point. This is generally bad, since it destroys the useful call stack information which lead up to the original problem.

throw releases the original caught exception, from the point it was actually thrown. It retains the call stack information up to that point, instead of to the point you caught.

catch(Exception) and catch are essentially the same thing, except obviously the first gives you the exception object to do something with, and the second does not. But both will catch all exceptions. They are distinct from catch(SomeKindOfException), which will only catch exceptions of that specific type (or more specific types derived from that type). This is best for situations like:

try
{
    //some file operation
}
catch(FileNotFoundException fnfex)
{
    //file not found - we know how to handle this
}
//any other kind of exception,
//which we did not expect and can't know how to handle,
//will not be caught and throw normally

Answer 5

Using catch without a parameter was useful in framework 1.x to catch exceptions thrown from unmanaged code. From framework version 2 (IIRC) all unmanaged exceptions are wrapped in a managed Exception object, so there is no use for the parameterless catch any more.

The parameterless throw is not specific for the parameterless catch, it can be used in any catch block. The difference is that when retrowing an exception using throw; it doesn't overwrite the stack trace from when the exception was originally thrown, so that is the correct way of rethrowing an exception.

Instead of using throw ex; in a catch block you should throw a newly created exception containing the information that you want to add, with the original exception as the inner exception. That way you get both the original point of failure, and the point where you caught it and rethrew it.

So, you should never use either of the combinations in the examples in your question. You always specify the exception type, and you either just retrow the exception:

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

or you throw a new exception with an inner exception:

catch (Exception ex) {
   ...
   throw new ApplicationException("Ooops!", ex);
}

Note that you should rarely catch the Exception base class, but a more specific exception class that is appropriate for the error that you anticipate. There is usually no point in catching an exception that you don't know how to handle.