Rethrowing does not work?

[valentin tihomirov]

I do not understand something. A caught exception stack points to an
argument-free 'throw' in a catch block. Meantime, it is widely known that
these statements re-throw the original exceptions. I expected, therefore,
that the stack points to the original 'throw e' code line.

[Nicholas Paldino [.NET/C# MVP]]

valentin,

Nope, it does not. If you rethrow the original exception with "throw
e", then the point from which you threw the exception changed, resetting the
call stack on the exception.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"valentin tihomirov" <V_*********@be st.eewrote in message
news:Ow******** ******@TK2MSFTN GP02.phx.gbl...

>I do not understand something. A caught exception stack points to an
argument-free 'throw' in a catch block. Meantime, it is widely known that
these statements re-throw the original exceptions. I expected, therefore,
that the stack points to the original 'throw e' code line.

[valentin tihomirov]

Oh, excuse me. I had rewise my data. It seems that both 'throw' and 'throw
e' rethrow
http://msdn2.microsoft.com/en-us/lib...sw(VS.71).aspx But my
previous data told that 'throw', given a throwable object, raises a new
exception. And that is the difference. The 2nd google match on "c# rethrow"
affirms this http://bartdesmet.net/blogs/bart/arc...3/12/3815.aspx

Anyway, I do not understand why re-throw overwrites the line of code where
exception was raised by the line where it was re-thrown. My rationale is
that the call stack makes value pointing to the cause of the exception
rather than the last place where it was handeled.

[Jon Skeet [C# MVP]]

valentin tihomirov <V_*********@be st.eewrote:

I do not understand something. A caught exception stack points to an
argument-free 'throw' in a catch block. Meantime, it is widely known that
these statements re-throw the original exceptions. I expected, therefore,
that the stack points to the original 'throw e' code line.

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

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

[valentin tihomirov]

I'm sure it is pretty obvious. But if you like

using System; // line 1

class Rerise {

public static void Main(string[] args) {

try {
throw new Exception("Can I escape?"); // line 8
} catch (Exception e) {
Console.WriteLi ne("Logged error: " + e.Message);
throw e; // line 11
}
}
}

Compile it with /debug key and see that stack trace will point to 'line 11'
where it is rethrown rather than to 'line 8' where it originates.

[Nicholas Paldino [.NET/C# MVP]]

As it should be. The spec is pretty clear on this, when you throw an
exception, the stack trace originates from the point of where it is thrown,
except when there is no exception stated with the throw statement, in which
case, the original exception is allowed to bubble up without having its
stack trace modified.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"valentin tihomirov" <V_*********@be st.eewrote in message
news:uM******** ******@TK2MSFTN GP03.phx.gbl...

I'm sure it is pretty obvious. But if you like

using System; // line 1

class Rerise {

public static void Main(string[] args) {

try {
throw new Exception("Can I escape?"); // line 8
} catch (Exception e) {
Console.WriteLi ne("Logged error: " + e.Message);
throw e; // line 11
}
}
}

Compile it with /debug key and see that stack trace will point to 'line
11' where it is rethrown rather than to 'line 8' where it originates.

[Ben Voigt [C++ MVP]]

"valentin tihomirov" <V_*********@be st.eewrote in message
news:uM******** ******@TK2MSFTN GP03.phx.gbl...

I'm sure it is pretty obvious. But if you like

using System; // line 1

class Rerise {

public static void Main(string[] args) {

try {
throw new Exception("Can I escape?"); // line 8
} catch (Exception e) {
Console.WriteLi ne("Logged error: " + e.Message);
throw e; // line 11
}
}
}

Compile it with /debug key and see that stack trace will point to 'line
11' where it is rethrown rather than to 'line 8' where it originates.

That is a throw, not a rethrow.

Change the line to "throw;" if you want the call stack preserved.

>

[valentin tihomirov]

As it should be. The spec is pretty clear on this, when you throw an

exception, the stack trace originates from the point of where it is
thrown, except when there is no exception stated with the throw statement,
in which case, the original exception is allowed to bubble up without
having its stack trace modified.

Why then it should not "bubble up without having its stack trace modified"
if it is allowed? Why it overwirtes the stack with the rethrow location?
Hiding the exception reason from user defeats the whole value of stack
trace.

[Ben Voigt [C++ MVP]]

"valentin tihomirov" <V_*********@be st.eewrote in message
news:uL******** ******@TK2MSFTN GP06.phx.gbl...

Oh, excuse me. I had rewise my data. It seems that both 'throw' and 'throw
e' rethrow
http://msdn2.microsoft.com/en-us/lib...sw(VS.71).aspx But my

Looks like a documentation error to me.

previous data told that 'throw', given a throwable object, raises a new
exception. And that is the difference. The 2nd google match on "c#
rethrow" affirms this
http://bartdesmet.net/blogs/bart/arc...3/12/3815.aspx

Anyway, I do not understand why re-throw overwrites the line of code where
exception was raised by the line where it was re-thrown. My rationale is
that the call stack makes value pointing to the cause of the exception
rather than the last place where it was handeled.

[Ben Voigt [C++ MVP]]

"valentin tihomirov" <V_*********@be st.eewrote in message
news:eu******** ******@TK2MSFTN GP04.phx.gbl...

> As it should be. The spec is pretty clear on this, when you throw an
exception, the stack trace originates from the point of where it is
thrown, except when there is no exception stated with the throw
statement, in which case, the original exception is allowed to bubble up
without having its stack trace modified.

Why then it should not "bubble up without having its stack trace modified"
if it is allowed? Why it overwirtes the stack with the rethrow location?
Hiding the exception reason from user defeats the whole value of stack
trace.

"throw e" performs certain steps, including setting up a stack trace.
Doesn't matter if e was thrown before, it makes a new stack trace. This
allows you to do things like preallocate or reuse exception objects.

Also, some libraries might want to hide where an exception actually
occurred, because the programmers feel that threatens their intellectual
property. Seems ridiculous to you and me, but some people think that way.