Re: Sanity Check: Custom Exception Approach
From: Dave (noSpamdlevineNNTP2_at_wi.rr.com)
Date: 03/25/04
- Next message: Andreas Håkansson: "Re: Name of the current function / class"
- Previous message: christian ternek: "how to post an event or function?"
- In reply to: Jeff S: "Re: Sanity Check: Custom Exception Approach"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 25 Mar 2004 05:22:53 -0600
>
> One surprising discovery for me is that when I pass the various Exception
> objects to an error logging routine (which writes details out to an XML
> file), the StackTrace associated with the exception (e.g.,
> SqlException.StackTrace) does not include the entire call stack (at least
it
> does not show all the modules/methods invoked from the start of the
> application and leading up to the error). However, at the same time - the
> same point in execution time - the Environment.StackTrace does contain the
> entire call stack.
This is the expected behavior. The exception object captures the stack from
the point where the exception occurred to where the exception was caught -
this is not the entire stack. Also, if you use the StackTrace property
directly you will get the stack trace for only that exception object, but
not for any innerExceptions. If you want a dump for all the chained
exceptions then user the exception.ToString() method (or run the chain
yourself).
If you call Environment.StackTrace in the catch handler you will see a
different stack due to the nature of how Structured Exception Handling (SEH)
works in .net. This uses a 2 pass mechanism when an exception occurs. The
1st pass locates a catch block for the exception, and the 2nd pass unwinds
stack frames, executing finally and fault blocks, up to the frame of the
catch handler. By the time the code in the catch handler executes the stack
has already been unwound from the point of the exception to the catch
handler. This means that if you capture the stack at that point you will
not see the frames that actually threw the exception - those frames have
been unwound (finally blocks executed) and popped off the stack.
> Put another way, when the program is executing the
> logging routine (in a static helper class), the two call stacks are not
> equal. They are not equal in entries leading up to the point of the
> exception, and of course only the Environment.StackTrace includes the call
> to the error logging routine itself (but that's not a surprise).
> Consequently in order to log everything I want to know about the
StackTrace,
> I am getting different pieces of information from the two different Stack
> Traces. I'd be interested in knowing what the difference is because I
> thought there was just one stack - and if there is, then any stacktrace
> should show what's on it.
>
Basically, the exception object preserves the stack frames for reporting
purposes and then pops the stack; Environment.StackTrace reports on the
current stack but knows nothing about what happened before that point.
Dave
- Next message: Andreas Håkansson: "Re: Name of the current function / class"
- Previous message: christian ternek: "how to post an event or function?"
- In reply to: Jeff S: "Re: Sanity Check: Custom Exception Approach"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
