Bug?! throw vs. throw ex

[GoogleNewsReaderMan]

I want to "rethrow" an exception so as not to lose the original stack
trace information. I understood that I could use throw, like:

try {
DoIt();
}
catch (Exception ex) {
DoSomeExceptionStuff(ex);
throw;
}


However, this apparently does NOT preserve the stack trace--it loses it
just like using throw ex; does! I am currently using .NET 1.1 SP1. Is
this a known bug? Why do so many people report that it works for them?
Have they actually tried it?

Why would a bug like this exist in v. 1.1 SP1?
Can anyone help shed some light on this?

Thanks in advance.

 

[Alvin Bruney [MVP]]

the rethrow does not preserve the stack. it is not a bug. You need preserve
the stack and then throw a new exception with the amended stack

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://tinyurl.com/27cok

 

[Guest]

I want to "rethrow" an exception so as not to lose the original stack

trace information.

I believe the stack trace is populated as part of the throw, not when the
exception object is created.

Create a new exception and stuff the old one inside it as the "inner
exception". The new one should have the new stack trace and the old one the
original stack trace.

 

[Jako Menkveld]

Not sure if it works, but try

throw new Exception("some message", ex)

 

[David Levine]

Yes, it's a bug. It is supposed to be fixed in Whidbey. For now you will
need to wrap the exception in a new exception object and use the original
exception as the inner exception.

 

[Jon Skeet [C# MVP]]

the rethrow does not preserve the stack. it is not a bug. You need preserve
the stack and then throw a new exception with the amended stack

Not true. Try this:

using System;

class Test
{
static void Main()
{
try
{
DoSomething();
}
catch (Exception e)
{
Console.WriteLine (e);
}
}

static void DoSomething()
{
try
{
DoSomethingNaughty();
}
catch (Exception)
{
throw;
}
}

static void DoSomethingNaughty()
{
string x = null;
bool y = x.Equals("hello");
}
}

Compile it with debug turned on and run it. I get a stack trace of:
System.NullReferenceException: Object reference not set to an instance
of an object.
at Test.DoSomethingNaughty() in c:\test\Test.cs:line 32
at Test.DoSomething() in c:\test\Test.cs:line 25
at Test.Main() in c:\test\Test.cs:line 9

 

[Helge Jensen]

Not sure if it works, but try

throw new Exception("some message", ex)

That would give you a new exception, with this place as stack-trace and
the old exception (with the old stack-trace) as it's "Inner" exception.

I have come to almost loathe the above way of coding, since it means
that catchers cannot use the type of the exception to dispatch to a
catch-handler but has to catch Exception and to analysis on the content
of e.Inner.

This is especially interesting with Delegate, which throws a wrapped
exception if invoking the Delegate throws an exception (/me holds back a
swarm of swearwords).

The difference between "throw e;" and "throw;" is that "throw;" rethrows
the original catch'ed exception unchanged (like in C++) whereas "throw
e"; throws the expression e, which happens to refer to a catch'ed
exception object.

 

[Alvin Bruney [MVP]]

I get the same results as you. I stand corrected.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://tinyurl.com/27cok

 

[GoogleNewsReaderMan]

One arguable flaw here, though, is that you lose the location within
the DoSomething() method --- the line number is that of the throw. So,
in fact, the stack trace is modified, and not that of the original
exception.

 

[danielshanyfelt]

Gentlemen,

There seem to be a lot of experts replying to this thread so I will add
my own question. If you wanted to get the same exception at a higher
level, why would you catch it at all?

for example (modifying the previous code):

using System;

class Test
{
static void Main()
{
try
{
DoSomething();
}
//handle all exceptions without bias on moral behavior
catch (Exception e)
{
Console.WriteLine (e);
}
}

static void DoSomething()
{
try
{
DoSomethingNaughty();
}
catch (NaughtyException)
{
//handle the offending problem
}
//let all of the less ethicly challenged exceptions bubble up
the the calling Main()
}

static void DoSomethingNaughty()
{
string x = null;
bool y = x.Equals("hello");
}
}

If I wanted to do some intermediate processing in the routine and then
still post an error to the calling method, I would throw a new
exception (of whatever type) with the original exception as the inner
exception. Does stuffing the old exception into the new still mess up
the stack?

Thanks,
Dan

 

[GoogleNewsReaderMan]

There are as many reasons to catch an exception at a lower level as
there are programs. (i.e. I can't think of all reasons, but there are
many.)

One is logging the exception.

Stuffing an inner exception into a newly thrown one isn't always the
most elegant solution. Logging is a case in point--I may want to note
the exception and simply pass it on up. I wouldn't want to wrap it in
another exception just because I logged it.

 

[Jay B. Harlow [MVP - Outlook]]

GoogleNewsReaderMan,
Isn't that a matter of perspective?

The stack trace below(above?) DoSomething is preserved.

The stack trace within DoSomething is the line that threw the exception (The
throw itself).

The stack trace above(below?) DoSomething is maintained.

Although I can see the flip side also, if there were multiple calls to
DoSomethingNaughty within DoSomething you would not be certain which call
threw the original exception...

Interesting I never specifically noticed that throw by itself modified the
entry for the routine it was in...

I'm curious what VB.NET's When clause does to the stack trace now...

Thanks for the info
Jay

One arguable flaw here, though, is that you lose the location within
the DoSomething() method --- the line number is that of the throw. So,
in fact, the stack trace is modified, and not that of the original
exception.

 

[GoogleNewsReaderMan]

GoogleNewsReaderMan,

Isn't that a matter of perspective?

Yes, that's why I said it was "arguable." Technically, the stack trace
is correct because the last location was that of the throw. But it
isn't what I want in all circumstances.

Although I can see the flip side also, if there were multiple calls to
DoSomethingNaughty within DoSomething you would not be certain which call
threw the original exception...

Precisely!

GoogleNewsReaderMan,
Isn't that a matter of perspective?

The stack trace below(above?) DoSomething is preserved.

The stack trace within DoSomething is the line that threw the exception (The
throw itself).

The stack trace above(below?) DoSomething is maintained.

Although I can see the flip side also, if there were multiple calls to
DoSomethingNaughty within DoSomething you would not be certain which call
threw the original exception...

Interesting I never specifically noticed that throw by itself modified the
entry for the routine it was in...

I'm curious what VB.NET's When clause does to the stack trace now...

Thanks for the info
Jay