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

[<Lar...@re...>]

2006-11-02 kl. 14.34 skrev Eckhard Lehmann:
>
>>
>>>  SPECIFICATION
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> [...]
>>
>> IMHO, this is not a specification, but rather a ChangeLog.
>
> I know.. sorry, I did'nt TIP before ;-). Its updated and hopefully=20
> better now.

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 fire=20=

differently with the TIP mechanisms in place than without them?

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.

>> Attempting to recreate a functionality description from the=20
>> information
>> given, it seems like these error handlers would be called immediately
>> when the error is thrown, just like e.g. a variable trace is called
>> immediately when that variable is accessed. In view of that, it might
>> perhaps be more appropriate to fully integrate this into the [trace]
>> command (especially since this would provide established mechanisms=20=

>> for
>> introspection and handler deletion).
>
> I thought about a [trace set errorcmd] or [trace add errorcmd].

I'd go for [trace add error].

> 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?

>> (Even counting [catch]es could be handled using execution traces,
>> if one trusts the user not to rename the [catch] command.) Speed is =
of
>> course an issue, but if that is the main reason for this feature then
>> the TIP should say so.
>
> As for the [catch]'es - I don't know how to capture them in a=20
> leavestep trace.

No, a *leavestep* trace could be a bit roundabout. I'd do that bit by=20
putting *enter* and *leave* traces on [catch] that increment/decrement=20=

a variable.

> Its not obvious or easy, if possible at all. The speed issue is=20
> included in the TIP now.
>
>>
>> The distinction between caught and uncaught errors also seem a bit
>> hazy. Many errors are caught (by control structures and the like) =
just
>> to be rethrown, but it seems as the mechanism proposed here would
>> simply consider them to be caught.
>
> 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. With something like=20
http://wiki.tcl.tk/using, you don't get the requested chance to debug=20
errors that happen within the [using], since that command catches and=20
rethrows errors.

Lars Hellstr=F6m=