Is there a way to process errors before the TCL embedded error handling proc?

[Frank]

I don't/can't/wan't use catch or try for this.

What I would like to is have a generic error handling routine that will be invoked before the general TCL error handling code.

Example 1: The user sources their own TCL code into my application.
if an error is detected:
1) typo on TCL instruction
2) missing variable definition before its use
3) etc.

Example 2: User provides wrong input data into my application.
if an error is detected:
1) wrong name
2) wrong time
3) wrong file
4) etc.

I would like to have my own generic error handling code to capture and analyze the error message.

Note: The error could be generated by the main TCL code via "error" or caused by a general TCL error detection condition.

I would like two options on the my error handling proc.
1) If I recognize the error handle the error myself.
2) If I don't sent it to the general TCL error handling code.


Thanks in advance.

[Don Porter]

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.
>
> Example 1: The user sources their own TCL code into my application.
> if an error is detected:
> 1) typo on TCL instruction
> 2) missing variable definition before its use
> 3) etc.
>
> Example 2: User provides wrong input data into my application.
> if an error is detected:
> 1) wrong name
> 2) wrong time
> 3) wrong file
> 4) etc.
>
> I would like to have my own generic error handling code to capture and analyze the error message.

Handling a subset of possible errors and re-raising the rest
is what [try] is designed to do with ease.

> Note: The error could be generated by the main TCL code via "error" or caused by a general TCL error detection condition.
>
> I would like two options on the my error handling proc.
> 1) If I recognize the error handle the error myself.
> 2) If I don't sent it to the general TCL error handling code.
>
>
> Thanks in advance.
>

--
| Don Porter Applied and Computational Mathematics Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|

[Robert Heller]

rename error _syserror
proc error {message {info {}} {code {}}} {
# Handle the error here
# possibly call _syserror as needed/desired, or maybe return -code ...
}

man n error
man n rename



>
> Thanks in advance.
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Matthew Hiles]

I don't have enough context to know if this is a good suggestion or a terrible one, but you may want to consider a separate [interp] if you're running someone else's / potentially unsafe code. You can asynchronously communicate between interps using [chan pipe]s.

This way you can let the slave interp show whatever error it has to the user, without disrupting your master interp.

[Frank]

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

Thanks again.

[Eric]

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