accessing StackTrace inside an exception ?

[Barry Mossman]

Hi,

I am throwing an exception derived from ApplicationException as follows
catch (Exception ex) {
throw new MyException("message", ex);
}

My exception's constructor is:
public ExceptionBase(string aMessage, Exception aInnerException):
base(aMessage, aInnerException)

In the constructor I am finding that "this.StackTrace" is blank, while
"aInnerException.StackTrace" is populated with class name, method and
failing line number as expected. "this.Message" works as expected.
"this.GetType().Name" also works ok.

Is my exception's StackTrace property unpopulated because I am still
inside the Exception's constructor. If so, how do I write MyException
code that will fire after the constructor has completely built the
Exception ?

thanks

Barry Mossman

 

[avnrao]

you can use Environment.StackTrace to find out the stack trace.

Av
http://dotnetjunkies.com/WebLog/avnrao
http://www28.brinkster.com/avdotnet

 

[Barry Mossman]

you can use Environment.StackTrace to find out the stack trace.

Hi, thanks for the response.

I had tried Environment.StackTrace, but it gives me a great long string
showing all stack frames with the point that actually produced the error
n levels deep, depending upon how many overloaded constructors by
Exception class has, and the various calls within the System.Envionment
namespace to produce the answer.

The StackTrace property for the inner exception just gives me information
on just the stack frame that caused the inner exception.

At the moment I am creating my own StackTrace, and then discarding enough
entries to account for the overloaded constructors involved in
constructing my exception. I then take just the next frame to identify
the method name & line number that caused the problem.

I was hoping for something more elegant, ie. how to use the Exception's
StackFrame property AFTER it was populated, but before I lose control due
to the thrown exception.

Barry Mossman

 

[David Levine]

The stack trace that is in the exception object's StackTrace property starts
where the exception was thrown and ends at the current stack frame (i.e.
where it is caught). It can't fill in the stack trace of the new exception
object because not only has it not been caught (thus reaching the end of the
stack trace), it hasn't been thrown yet so it does not know where it should
start.

One reason for this is because simply creating an exception object does not
mean that it is immediately thrown - you can create on exception object and
use it anywhere, or reuse the same one - so the runtime does not fill in the
stack trace at the moment it is created.

The stack trace ends where it is caught - my understanding is that one
reason was for performance. It is faster to end the stack trace there rather
then walk the entire stack. You can do that on your own if you need the full
stack trace.

 

[Barry Mossman]

The stack trace that is in the exception object's StackTrace property
starts where the exception was thrown and ends at the current stack
frame (i.e. where it is caught). It can't fill in the stack trace of
the new exception object because not only has it not been caught (thus
reaching the end of the stack trace), it hasn't been thrown yet so it
does not know where it should start.

One reason for this is because simply creating an exception object does
not mean that it is immediately thrown - you can create on exception
object and use it anywhere, or reuse the same one - so the runtime does
not fill in the stack trace at the moment it is created.

The stack trace ends where it is caught - my understanding is that one
reason was for performance. It is faster to end the stack trace there
rather then walk the entire stack. You can do that on your own if you
need the full stack trace.

Thanks David, it makes more sense to me now.

What I am seeing is an empty string while I am in the constructor, which
fits it in with what you are saying.

As I said in a different post to the one that you answered, I have a work
around where I create my own StackTrace inside the exception's
constructor, and then walk the frames until I found the one that I
thought triggered the exception. This sounds like it will be my final
solution.

Thanks for explaining the rationale behind what i am observing.

Barry Mossman