Prev: check record size before update
Next: Slider math
From: Larry Serflaten on 22 Feb 2010 09:53

"Phill W." <p-.-a-.-w-a-r-d-@-o-p-e-n-.-a-c-.-u-k> wrote

> You need to know /which/ function failed (the line number is a bonus but
> by no means essential) and the /data/ with which that function was called.
> Then you need to know which /other/ function called the one that failed
> and with what data and so on, all the way back up the chain.
> Yes; it's a pain having to add all the instrumentation code to keep
> track of this, but it makes for far more effective diagnosis.

Its rather amusing. I wrote a Log Manager article for a book that did this
sort of thing way back in 1998. As you say it requires the instrumentation
code to make it all work, but that kind of code can be automated.

Basically the program would call the manager at the start and end of every
procedure. The first call gives the procedure name and all the parameters,
and the exit call passes in the procedure name. From that, a current call
stack could be maintained all while the program runs, then saved to disk
(or shown to the user, or sent via email, whatever...) at the first sign of
trouble.

Its not that dificult to do, once you get past the idea that you want to
do it....

FYI: http://www.amazon.com/Waite-Groups-Visual-Source-Library/dp/0672313871

LFS


First  |  Prev  | 
Pages: 1 2 3
Prev: check record size before update
Next: Slider math