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) {
DoSomeException Stuff(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.

[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.
danielshanyf... @yahoo.com wrote:

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.WriteLi ne (e);
}
}

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

static void DoSomethingNaug hty()
{
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

[Jay B. Harlow [MVP - Outlook]]

GoogleNewsReade rMan,
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
DoSomethingNaug hty 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

"GoogleNewsRead erMan" <lo***********@ hotmail.com> wrote in message
news:11******** **************@ l41g2000cwc.goo glegroups.com.. .

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.
Jon wrote:

<"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:

> 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.WriteLi ne (e);
}
}

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

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

Compile it with debug turned on and run it. I get a stack trace of:
System.NullRefe renceException: Object reference not set to an

instance

of an object.
at Test.DoSomethin gNaughty() in c:\test\Test.cs :line 32
at Test.DoSomethin g() in c:\test\Test.cs :line 25
at Test.Main() in c:\test\Test.cs :line 9

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[GoogleNewsReaderMan]

> GoogleNewsReade rMan,

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 DoSomethingNaug hty within DoSomething you would not be certain which call threw the original exception...
Precisely!
Jay B. Harlow [MVP - Outlook] wrote: GoogleNewsReade rMan,
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 DoSomethingNaug hty 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

"GoogleNewsRead erMan" <lo***********@ hotmail.com> wrote in message
news:11******** **************@ l41g2000cwc.goo glegroups.com.. .

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.
Jon wrote:

<"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:
> 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.WriteLi ne (e);
}
}

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

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

Compile it with debug turned on and run it. I get a stack trace

of: System.NullRefe renceException: Object reference not set to an

instance

of an object.
at Test.DoSomethin gNaughty() in c:\test\Test.cs :line 32
at Test.DoSomethin g() in c:\test\Test.cs :line 25
at Test.Main() in c:\test\Test.cs :line 9

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too