Re-Throwing Exceptions

[sternr]

Hey,
I use the following code:
try
{
//Some code that has an exception
}
catch (Exception ex)
{
if (ex.innerExcept ion!=null) {throw ex.innerExcepti on;}
}

All works well, but the problem is that the exception's stacktrace is
changed because of the throw!

Is there a way to throw an exception WITHOUT changing it's stacktrace?
Thanks ahead

--sternr

[.neter]

sternr wrote:

Hey,
I use the following code:
try
{
//Some code that has an exception
}
catch (Exception ex)
{
if (ex.innerExcept ion!=null) {throw ex.innerExcepti on;}
}

All works well, but the problem is that the exception's stacktrace is
changed because of the throw!

Is there a way to throw an exception WITHOUT changing it's stacktrace?
Thanks ahead

--sternr

Why the stacktrace should be left unchanged in case of re-throwing the
same exception? When its thrown again the stacktrace should be updated.
But if you rethrow the outer exception (ex in your example) instead of
innerException, the inner exceptions's stack trace will be unchanged.
rg

[Alvin Bruney]

just simply throw; will work. it's rather pointless IMO to catch an
exception and rethrow the inner exception? Why would that be helpful?

--

_______________ _________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin
-------------------------------------------------------

"sternr" <St****@gmail.c om> wrote in message
news:11******** **************@ j55g2000cwa.goo glegroups.com.. .

Hey,
I use the following code:
try
{
//Some code that has an exception
}
catch (Exception ex)
{
if (ex.innerExcept ion!=null) {throw ex.innerExcepti on;}
}

All works well, but the problem is that the exception's stacktrace is
changed because of the throw!

Is there a way to throw an exception WITHOUT changing it's stacktrace?
Thanks ahead

--sternr

[Jon Skeet [C# MVP]]

<"Alvin Bruney" <www.lulu.com/owc>> wrote:

just simply throw; will work.
No, that will rethrow the *outer* exception.
it's rather pointless IMO to catch an
exception and rethrow the inner exception? Why would that be helpful?

There are cases where a known level of wrapping occurs, and you want to
get rid of that so that the real exception is reported immediately. For
instance, if you're creating an instance of a plugin using reflection,
it might make sense to catch TargetInvocatio nException and rethrow the
inner exception. The TargetInvocatio nException should basically be
ignored by anyone looking at a stack trace anyway, and it's just extra
clutter.

--
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

[Alvin Bruney]

> There are cases where a known level of wrapping occurs, and you want to

get rid of that so that the real exception is reported immediately. For
instance, if you're creating an instance of a plugin using reflection,
it might make sense to catch TargetInvocatio nException and rethrow the
inner exception. The TargetInvocatio nException should basically be
ignored by anyone looking at a stack trace anyway, and it's just extra
clutter.
hmm, in that case - and it is not the usual or the typical case - it makes
more sense to throw your own exception because you are actually applying
logic to the original exception object. Such logic should be localized to
prevent code bloat and improve source code maintainability .

--

_______________ _________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin
-------------------------------------------------------

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com... <"Alvin Bruney" <www.lulu.com/owc>> wrote:

just simply throw; will work.

No, that will rethrow the *outer* exception.

it's rather pointless IMO to catch an
exception and rethrow the inner exception? Why would that be helpful?

There are cases where a known level of wrapping occurs, and you want to
get rid of that so that the real exception is reported immediately. For
instance, if you're creating an instance of a plugin using reflection,
it might make sense to catch TargetInvocatio nException and rethrow the
inner exception. The TargetInvocatio nException should basically be
ignored by anyone looking at a stack trace anyway, and it's just extra
clutter.

--
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

[Jon Skeet [C# MVP]]

<"Alvin Bruney" <www.lulu.com/owc>> wrote:

There are cases where a known level of wrapping occurs, and you want to
get rid of that so that the real exception is reported immediately. For
instance, if you're creating an instance of a plugin using reflection,
it might make sense to catch TargetInvocatio nException and rethrow the
inner exception. The TargetInvocatio nException should basically be
ignored by anyone looking at a stack trace anyway, and it's just extra
clutter.

hmm, in that case - and it is not the usual or the typical case - it makes
more sense to throw your own exception because you are actually applying
logic to the original exception object. Such logic should be localized to
prevent code bloat and improve source code maintainability .

I would say that the original exception is the most reasonable one -
it's what we *would* have got if we'd been able to call the constructor
directly instead of having to use reflection. Why introduce an extra
level of indirection with no benefit?

I agree it's a rare case, but it can happen.

--
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

[sternr]

Hey Jon,
The scenario you mentioned before is exactly the reason for my
question:
I call a method using reflection, and want to be able to catch the
exception
Thrown from this method without the wrapping TargetInvocatio nException.
The solution I did is as follows:

catch (Exception ex)
Type type;
Assembly assembly;
object newEx;
type=ex.GetType ();
assembly=Assemb ly.GetAssembly( ex);
newEx=assembly. CreateInstance( ex.FullName,fal se,BindingFlags .CreateInstance ,null,new
object[]{ex.InnerExcept ion.Message,ex. InnerException} ,System.Globali zation.CultureI nfo.CurrentCult ure,null);
}
Enjoy ;)

Jon wrote:

<"Alvin Bruney" <www.lulu.com/owc>> wrote:

There are cases where a known level of wrapping occurs, and you want to
get rid of that so that the real exception is reported immediately. For
instance, if you're creating an instance of a plugin using reflection,
it might make sense to catch TargetInvocatio nException and rethrow the
inner exception. The TargetInvocatio nException should basically be
ignored by anyone looking at a stack trace anyway, and it's just extra
clutter.

hmm, in that case - and it is not the usual or the typical case - it makes
more sense to throw your own exception because you are actually applying
logic to the original exception object. Such logic should be localized to
prevent code bloat and improve source code maintainability .

I would say that the original exception is the most reasonable one -
it's what we *would* have got if we'd been able to call the constructor
directly instead of having to use reflection. Why introduce an extra
level of indirection with no benefit?

I agree it's a rare case, but it can happen.

--
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

[Jon Skeet [C# MVP]]

sternr <St****@gmail.c om> wrote:

The scenario you mentioned before is exactly the reason for my
question:
I call a method using reflection, and want to be able to catch the
exception
Thrown from this method without the wrapping TargetInvocatio nException.
The solution I did is as follows:

Why are you creating a *new* instance of the inner exception, rather
than just using:

throw ex.InnerExcepti on;

?

That would be a lot neater, and wouldn't rely on there being a
constructor with (string, Exception) parameters for the type of
exception thrown.

--
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

[David Levine]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

sternr <St****@gmail.c om> wrote:

The scenario you mentioned before is exactly the reason for my
question:
I call a method using reflection, and want to be able to catch the
exception
Thrown from this method without the wrapping TargetInvocatio nException.
The solution I did is as follows:

Why are you creating a *new* instance of the inner exception, rather
than just using:

throw ex.InnerExcepti on;

?

That would be a lot neater, and wouldn't rely on there being a
constructor with (string, Exception) parameters for the type of
exception thrown.

There are side effects to the throw statement - it resets the stack trace so
you lose the original stack. There's no way to avoid this, so unless that
is a desired side-effect I would use a different technique. I find it more
useful to wrap the innerexception in some other exception to add context and
preserve the stack.

[Jon Skeet [C# MVP]]

David Levine <Sn************ *************@w i.rr.com> wrote:

Why are you creating a *new* instance of the inner exception, rather
than just using:

throw ex.InnerExcepti on;

?

That would be a lot neater, and wouldn't rely on there being a
constructor with (string, Exception) parameters for the type of
exception thrown.

There are side effects to the throw statement - it resets the stack trace so
you lose the original stack. There's no way to avoid this, so unless that
is a desired side-effect I would use a different technique. I find it more
useful to wrap the innerexception in some other exception to add context and
preserve the stack.

I agree that there are side-effects which are undesirable in this case
(as per the first message), but the OP's proposed "solution" doesn't
seem to fix this, it just introduces complexity and constraints as far
as I can see.

--
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