On Fri, Oct 24, 2008 at 3:18 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
> Will Coleda wrote:
>>
>> Allison Randal wrote:
>>>
>>> ...you expect 'rethrow' to keep the stack trace of the original 'die'?
>>
>> Yes.
>
> The way to do this is to add stack trace information to the Exception's
> 'stacktrace' attribute when the exception is first thrown, and print that
> out for an unhandled exception, instead of printing out the literal current
> path of execution. (This is why I added the 'stacktrace' attribute.)
>
> But, the implementation isn't currently using this feature. Largely, we just
> haven't decided what information to store in 'stacktrace'. I'd say a data
> structure is more useful than a string, because it can be manipulated by
> various HLLs to the format of their stacktrace dumps. So, what information
> do the HLL developers want from the original stack trace?
>
> (I suppose technically we should stop calling this a "stack trace" since
> it's not a stack. But "return continuation chain trace" is just too
> verbose.)
>
> Allison
>
I'm not sure tcl has an actual spec on this (since there's just the
one implementation), but I need to be able keep track of HLL
file/line/proc/ and in some cases raw source. here's a sample I was
able to generate with tclsh8.5;
eek
while executing
"error eek"
(procedure "foo::bar" line 2)
invoked from within
"foo::bar"
(file "baz.tcl" line 1)
invoked from within
"source baz.tcl"
(file "bar.tcl" line 2)
tcl also has some global variables that get dragged into the error
handling ($::errorCode, and $::errorInfo); in fact, it's quite
possible that I could roll my own mechanism just by using $::errorInfo
and ignoring the stacktrace entirely.
I'm still interested in the parrot stacktrace for when a -parrot-
error occurs, though; debugging things when the original parrot trace
is clobbered is quite difficult, especially since -t doesn't always
work. (by which I mean fail in the same way as not using it.)
--
Will "Coke" Coleda
