Alexandre Ferrieux wrote:

>  Of course I have no objection regarding the API. It is trivial to
>  expose it through the [info] or [interp] ensembles rather than
>  variables. I'm just surprised to see this as a strong showstopper,
>  because I seem to recall some of you saying that the ::tcl namespace
>  was okay for the job.

>  Now to proceed is:
>       info errorstack --> gives the list
>       info errorstack <boolean> --> enables/disables the feature
>  Minor variations:
>      - "interp" ensemble instead of "info"
>      - boolean replaced or extended by "enable/disable"


Where this really belongs is in the return options dictionary:

    catch $script result options
    dict get $options -errorstack

Of course to be truly useful the error stack *also*
needs to be accessible via [info] or [interp],
for the benefit of those who neglected to catch
the return options before making an error :-)

I'd suggest: [info errorstack ?interp?], where ?interp?
defaults to the calling interpreter if omitted.

As for how to turn it on and off -- I think it'd be OK,
preferable even, to just leave this enabled all the time.
The feature doesn't cost anything under normal operations,
the only additional work done is during error propagation,
which is not a time-critical part of any reasonable program.

Also, that way users don't need to remember to turn the feature
on before making a mistake that they will want to debug.

(BTW: I've since had a chance to look at the actual patch,
and agree that the basic mechanism is minimally intrusive;
I think it'd be OK for 8.6 (once amended).)


--Joe English

  jenglish@[...].com

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core