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?