Difference between

• <a href="Exception_throw_n_throw/Exception.zip">Download Exception.zip - 6.0 KB</a> 

Difference between "throw" and "throw ex"

Introduction

If you use Throw ex it overwrites the stack trace this makes it very hard to find the original line of the thrown exception.

In throw ex - the stack trace is truncated below the method that failed, means at the stack trace, it will look as if the exception originated in your code. This is a problem known as "breaking the stack", because you no longer have the full stack trace information. This happens because you are in essence creating a new exception to throw.

By using "throw" by itself, you preserve the stack trace information, you get the full stack trace including the line of the orginal exception that was thrown.

This makes the difference very obvious since in the first example the IL instruction called is "throw" while in the second the instruction is called "rethrow".

(Optional) Is there any background to this article that may be useful such as an introduction to the basic ideas presented?

Using the code

In MSIL, there are two instructions, throw and rethrow. "Throw ex" gets compiled into the throw instruction, while "throw" gets translated into rethrow.

When you rethrow an exception using just the "throw" statement ("rethrow" in MSIL), the original stack trace is maintained. However, if you rethrow an exception using "throw ex" ("throw" in MSIL), then the stack trace is reset to the point where you are throwing the exception. As an example, consider the following C#.NET console application:

Sample Project

class Program {

public void ProblemMethod() {

throw new Exception("Guess where this exception happened");

}

static void Main(string[] args) {

Program p = new Program();

try {

p.ProblemMethod(); }

catch(Exception ex) {

throw ex ; }

}

)

In this example, ProblemMethod() is throwing an exception, which is called by the Main() method and wrapped in a Try...Catch block. Our goal here is to have the stack trace identify the location of the exception as close as possible to the point that it was thrown. Here is the output depending on " throw ex " to rethrow the exception object, or if I simply " throw " statement and let the compiler translate that into the rethrow MSIL instruction.

Using throw...

at ConsoleApplication1.Program.ProblemMethod() in E:\ConsoleApplication1\ConsoleApplication1\Program.cs:line 63

at ConsoleApplication1.Program.Main(String[] args) in E:\ConsoleApplication1\ConsoleApplication1\Program.cs:line 77

Using throw ex...

at ConsoleApplication1.Program.Main(String[] args) in E:\ConsoleApplication1\ConsoleApplication1\Program.cs:line 77

Notice how in the second case, the error is reported as happening in the Main() method at the line that calls "ProblemMethod()". However, in the first case, when the stack trace is maintained, the exact line of code is identified, making it much easier to diagnose the error.

Points of Interest

Before you run and change all of your code, there are still places where "throw ex" is appropriate. There are times when you want to add information to the exception that was caught or change it into a more meaningful exception. In these instances you actually want a new exception to be thrown. Again, there are two ways you can do this. The most common way that I have seen is

1: try

2: {

3: // code to fail

4: }

5: catch (Exception ex)

6: {

7: // do some local code

8: throw new ApplicationException("operation failed!");

9: }

However, this still suffers the problem of breaking the stack. Here you are generating a completely new exception and loosing any of the stack trace information from the original exception. What you really want to do is

1: try

2: {

3: // code to fail

4: }

5: catch (Exception ex)

6: {

7: // do some local code

8: throw new ApplicationException("operation failed!", ex);

9: }

By passing the original exception to the ApplicationException you are preserving the original exception, and it's stack trace information, as the inner exception to your ApplicationException.

History

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here