stack tracing {was assert(condition[, message]) patch}

[BCS]

In article <e5odr1$2mis$1 at digitaldaemon.com>, James Dunne says...
>
[...]
>
>I'm sorry but I really have to insert my skepticism here about stack traces.
>
>Upon first glance it sounds like a wonderful idea, until you get to 
>where Java is at.  Literally hundreds of lines of stack traces dumped 
>into log files to wade thru, most of them completely useless because: 
>THEY DON'T CONTAIN STATE!!!
>

A lot of state can be gained with scope(failure) statements. I have a program
where (as an experiment) every function is prefaced with:

# scope(failure) writef("StackTrace@"__FILE__":"~itoa!(__LINE__)~\n);

If I needed some state a few more scope(failure) line would do this quite
nicely.

I will grant, just an automated stack trace might not be to useful, but throwing
in parameter values, called from info (line#) and the like would give you a good
idea where things stand.

OTOH if I was trying to run an automated bug tracking system that gets reports
from crashed sessions, a stack trace would be exactly where I would start.


>Sure they have the call-stack state so you can see where the function 
>calls came from but there are no local variables, no function parameter 
>values, no class/struct dumps; basically nothing useful for anything 
>more complex than the simplest case of a deterministic function call, 
>and even then it's not too terribly useful.
>
>While I agree that it is better than nothing, we can still do better. 
>An entire run-time debugging framework is what we really want to shoot 
>for.  Exception logging, tracing, dumping of object contents, reading 
>local variables, reading function parameters, etc.  This probably 
>requires the help of a compile-time reflection system (where certain 
>properties of objects are translated by the compiler into literal 
>expressions).  Run-time reflection isn't really necessary.
>
>-- 
>Regards,
>James Dunne