Re: [TCLCORE] TIP #290: Registration of Custom Error Handler Scripts

[Eckhard L. <ec...@we...>]

Lars Hellstr=F6m schrieb:
> It still doesn't describe the ::tcl::seterrorhandler command very much=20
> (syntax, return value, etc.). Nor is there much said about the handler=20
> command itself (With which arguments is it called? Is there any way in=20
> which it can quell the error?)
>
> One would also want the bulleted list after "The changes in the=20
> execution engine should be done so that:" to be followed by an=20
> explanation of how you mean to meet these conditions. For example, it=20
> is stated that the ::errorInfo and ::errorCode variables are updated.=20
> Does this mean that e.g. any write traces on these variables would=20
> fire differently with the TIP mechanisms in place than without them?

I updated the specification again. Hope that these questions are=20
answered now...

> Is there meant to be any interaction with the event loop? Having a=20
> Tk-based debugger probably means running the event loop (probably via=20
> [vwait]), and as far as I can tell this error handling mechanism is=20
> then turned off. However, the rest of the application (channel events,=20
> GUI events, [after] scripts) would continue to run, and do so without=20
> the "protection" of an error handler. This could be considered=20
> undesirable.
Good point... I didn't consider the event loop so far.
It would mean to be able to trigger the error handler again in event=20
loop scripts (e.g. in "after" code) , if it runs already at the same=20
time. Currently it can be only run once at a time - if errors in the=20
same Interp are thrown during the handler runs, they are handled as=20
usual. This is however different from the behaviour in different threads=20
since there are other Interp's.

>> I thought about a [trace set errorcmd] or [trace add errorcmd].
>
> I'd go for [trace add error].
I'd rather go for [trace set error], because it's only one command.
[trace add error] could mean that the script is run in addition to the=20
usual implementation (which is not the case) or that there can be more=20
scripts registered.
Technically, this wouldn't be a problem, but it makes things more=20
complicated than necessary. In general, one custom handler is enough -=20
it's again up to the implementor of this handler to call other procedures=
.

>> Probably you're right regarding the interface to this from a Tcl'ers=20
>> point of view. But the internal execution mechanism is different...
>
> More different than an execution trace is from a variable trace?

The error handler is to be run whenever the return code of the current=20
command is TCL_ERROR. I think that is maybe simpler than the "execution=20
trace" mechanism...

>> No, if they are rethrown, a new error is generated which is not=20
>> considered to be caught (if not caught elsewhere above, of course).
>
> Yes, but the rethrowing of an error could take place very far from=20
> where it originally happened.=20

It doesn't matter where it is thrown or rethrown. As soon as it appears,=20
it is trapped (provided, the -uncaught flag is set). That's the whole=20
point of this TIP.

> With something like http://wiki.tcl.tk/using, you don't get the=20
> requested chance to debug errors that happen within the [using], since=20
> that command catches and rethrows errors.
That's a rather special case. Set the -caught flag to trap caught=20
errors. This can be done dynamically during program run from somewhere...



Eckhard