On 2017-04-18, Frank <
kra...@gmail.com> wrote:
> On Tuesday, April 18, 2017 at 12:17:45 PM UTC-5, Don Porter wrote:
>> On 04/18/2017 12:51 PM, Frank wrote:
>>>
>>> I don't/can't/wan't use catch or try for this.
>>
>> There are two proper tools for the job. The first
>> is [catch]/[try] around your evaluation harness.
>> If you are directly evaluating, that's the proper
>> approach.
>>
>> The second is to use [interp bgerror] to set up
>> handling for errors in scripts evaluated during event
>> processing.
>>
>>>
>>> What I would like to is have a generic error handling routine that will
>>> be invoked before the general TCL error handling code.
>>>
8>< --------
>
> Hi Don,
>
> Thanks for the info. I am trying the interp approach.
>
> This is my first time playing with interp so I am not sure if I am doing
> things right.
>
> In order to find out the interpreter path I executed:
>
> interp slaves ; # Returns a Tcl list of the names of all the slave
> interpreters associated with the interpreter identified by
> path. If path is omitted, the invoking interpreter is used.
>
> Now that I have the interpreter path (interp0)
But there are no slaves until you create them - did you by any chance
do
interp create
at some point before this?
> I did:
>
> interp bgerror interp0
>
> It returned ::tcl::Bgerror which I am guessing is the default.
>
> I then proceeded to assign my proc as the error handler. I double checked
> that it is at the top of the execution stack (::my_error_handler_proc
> executes my proc).
>
> interp bgerror interp0 ::my_error_handler_proc
>
> If I do "interp bgerror interp0" it returns ::my_error_handler_proc
> as expected.
>
> I then proceed to generate an error (use of tcl var that is not defined):
>
> puts $my_bad_var
>
> My proc was not invoked but the normal TCL error message (can't read
> "my_bad_var": no such variable) was displayed.
>
> What am I missing? What am I doing wrong?
>
1. Your error handler would only apply for commands run in interp0.
2. Your error handler would not apply to commands typed at the prompt
even if they were in interp0.
The following is a quote from the throw manpage, but is true for all
errors no matter how they are created:
The stack will be unwound until the error is trapped by a suitable
catch or try command. If it reaches the event loop without being
trapped, it will be reported through the bgerror mechanism. If it
reaches the top level of script evaluation in tclsh, it will be
printed on the console before, in the non-interactive case, causing
an exit (the behavior in other programs will depend on the details of
how Tcl is embedded and used).
Your error handler should really have been set by
interp bgerror {} ::my_error_handler_proc
i.e. in the current interpreter, not in some arbitrary slave.
And then it would only be invoked if the error had occurred in something
called (ultimately) from the event loop meaning
- from some binding or generated event in a Tk widget
- from code set up as a fileevent
- from code run using after
For errors anywhere else, they land by default at the top level and are
printed to standard error. The _only_ way to deal with them as you want
is with try (or catch) - what is the point behind you original statement
about not using them?
Without Tk, errors which land in the event loop are printed to standard
error (but asynchronously), with Tk the normal error dialog is produced.
Eric
--
ms fnd in a lbry