Understanding the Stack Trace

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

While working with ASP.NET I've sometimes encountered errors in my applications, but I've always known exactly why I'm getting the error and have been able to fix it. So I've never needed to understand the Stack Trace, but I want to understand the stack trace so can somebody please explain it to me or point me to something that will

Thanks
Jeremy
 
Basically, the Stack Trace is a trace of function calls that go on the
Stack. When a program runs, it copies functions from the Heap to the Stack,
in a "Stack" (so to speak) which is a stack of the functions. When a
function is called, a copy of it is put on the Stack to execute. When a
function exits, it is pulled from the Stack. If it calls other functions,
these are stacked on top of it, and each one is pulled off the Stack when it
exits.

The Stack Trace shows the "topmost" (latest) functions called. It helps
identify the chain of execution that led up to the current situation
(usually an exception). It identifies each function on the Stack in the
order (reversed) in which they appear, with the last one executed at the
top.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

Jeremy said:
While working with ASP.NET I've sometimes encountered errors in my
applications, but I've always known exactly why I'm getting the error and
have been able to fix it. So I've never needed to understand the Stack
Trace, but I want to understand the stack trace so can somebody please
explain it to me or point me to something that will?
 
Kevin has a great technical explanation, so I will go to an analogy.

First, let's understand why the word Stack is applicable. Let's imagine a
deck of cards and you are playing solitaire. As you get to cards you cannot
play, you add them to the discard pile (or stack). Each card is stacked on
top of another one.

To equate to programming, Card1 (the first card on the discard pile) calls 2
which calls 3. You cannot finish working with card 1 until you have played
card 2 and card 3 (and so on). This would be like function Card1() calling
function Card2(), which calls function Card3. If you break inside the
Card3() function, you have a stack like so:

Card3
Card2
Card1

Now, let's say Card3 returns an answer that Card2 processes, and Card2 has
an error. The stack now looks like so:

Card2
Card1

In the stack trace, you will see Card2 with a line number and Card1 with a
line number, if you have the IDE set to break on all errors, or if you let
the error remain when deployed and do not have a Try ... Catch to handle the
error.

Sometimes what you do in your code does not throw an exception until it hits
the .NET Framework components. In these cases, you often have to look down
the stack until you hit your own functions to determine what actually caused
the error.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************
Jeremy said:
While working with ASP.NET I've sometimes encountered errors in my
applications, but I've always known exactly why I'm getting the error and
have been able to fix it. So I've never needed to understand the Stack
Trace, but I want to understand the stack trace so can somebody please
explain it to me or point me to something that will?
 
Back
Top