From Newsgroup: comp.lang.tcl

I have an event-driven script that occasionally becomes unresponsive.
The only way to restore it is to kill the process and start it over
again. It doesn't use threads, just file event handlers. An event comes
in and it calculates a response.

I am sure there are bugs, undefined variables and other stuff that can
stop the normal flow in some cases. However, shouldn't that just affect
that one event? I would expect that a new event would start things over without being concerned about the previous one getting stuck somewhere
in a series of nested calls.

Is that a correct statement?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/23/26 7:50 AM, saito wrote:

Is that a correct statement?

Event handlers are deleted after an error

https://www.tcl-lang.org/man/tcl9.0/TclCmd/chan.html#M24

"If an error occurs while executing the script then the command
registered with interp bgerror is used to report the error. In addition,
the file event handler is deleted if it ever returns an error; this is
done in order to prevent infinite loops due to buggy handlers."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/23/2026 12:17 PM, David Gravereaux wrote:

On 6/23/26 7:50 AM, saito wrote:

Is that a correct statement?

Event handlers are deleted after an error

Wow! This is totally unexpected. However it explains the behavior I see.

The man page says chan specifically but I assume it applies equally to sockets, pipes, file open's, etc. as well where one can assign an event handler?

Is there a way to log that problematic error message? Is there a proper
way to manage this apart from putting catch everywhere?

And thanks!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

saito <saitology9@gmail.com> wrote:

On 6/23/2026 12:17 PM, David Gravereaux wrote:

On 6/23/26 7:50 AM, saito wrote:

Is that a correct statement?

Event handlers are deleted after an error

Wow! This is totally unexpected. However it explains the behavior I see.

I believe it also has been Tcl's event model since way long ago.

The man page says chan specifically but I assume it applies equally to sockets, pipes, file open's, etc. as well where one can assign an event handler?

All are abstracted to a "channel" in the end from the Tcl script code
level, so it should apply no matter the actual underlying "device".

Is there a way to log that problematic error message?

You snipped the part of David's post pointing out that "If an error
occurs ... then the command registered with interp bgerror is used to
report the error.".

So presumably the bgerror functionality can be used to log the issue
that occurred.

Is there a proper way to manage this apart from putting catch
everywhere?

It sounds like 'bgerror' is the official way, although 'catching' (or
[try]) around things is an alternative.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/23/26 11:10 AM, Rich wrote:

Is there a proper way to manage this apart from putting catch
everywhere?

It sounds like 'bgerror' is the official way, although 'catching' (or
[try]) around things is an alternative.

proc bgerror {message} {
puts "background error in handler script: $message"
}

Something like that should get it
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/23/26 15:14, David Gravereaux wrote:

On 6/23/26 11:10 AM, Rich wrote:

Is there a proper way to manage this apart from putting catch
everywhere?

It sounds like 'bgerror' is the official way, although 'catching' (or
[try]) around things is an alternative.

proc bgerror {message} {
    puts "background error in handler script: $message"
}

Something like that should get it

Please no. That has been out of date more than a decade.

[interp bgerror] is available since Tcl 8.5. Use that.
--
| Don Porter Applied and Computational Mathematics Division |
| donald.porter@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________|
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/23/2026 3:14 PM, David Gravereaux wrote:

On 6/23/26 11:10 AM, Rich wrote:

Is there a proper way to manage this apart from putting catch
everywhere?

It sounds like 'bgerror' is the official way, although 'catching' (or
[try]) around things is an alternative.

proc bgerror {message} {
    puts "background error in handler script: $message"
}

Something like that should get it

Thanks again! Your first reply was helpful enough already to get to a resolution.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/23/2026 2:10 PM, Rich wrote:

saito <saitology9@gmail.com> wrote:

On 6/23/2026 12:17 PM, David Gravereaux wrote:

On 6/23/26 7:50 AM, saito wrote:

> Is that a correct statement?

Event handlers are deleted after an error

Wow! This is totally unexpected. However it explains the behavior I see.

I believe it also has been Tcl's event model since way long ago.

You are correct of course. I just don't remember reading it but I am
sure I must have if it is documented clearly like this.

I am working on some old code. It turns out that a custom bgerror was
defined under a different name. It was also registered properly with the interpreter. However, there was a silly syntax error in one of its
conditional branches which was causing the problem. I have just fixed
it; and for good, I hope.

Thanks to you, David, and Don. I am glad I posted about it. This has
been a learning experience.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/23/26 12:23 PM, Don Porter wrote:

On 6/23/26 15:14, David Gravereaux wrote:

On 6/23/26 11:10 AM, Rich wrote:

Is there a proper way to manage this apart from putting catch
everywhere?

It sounds like 'bgerror' is the official way, although 'catching' (or
[try]) around things is an alternative.

proc bgerror {message} {
     puts "background error in handler script: $message"
}

Something like that should get it

Please no.  That has been out of date more than a decade.

[interp bgerror] is available since Tcl 8.5.  Use that.

proc myBgHandler {message options} {
puts "--- Background Error Caught ---"
puts "Message: $message"
puts "Error Code: [dict get $options -errorcode]"
puts "Line Number: [dict get $options -errorline]"
puts "-------------------------------"
}

interp bgerror {} myBgHandler


Much nicer, thank you
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 23.06.2026 um 19:42 schrieb saito:

On 6/23/2026 12:17 PM, David Gravereaux wrote:

On 6/23/26 7:50 AM, saito wrote:

Is that a correct statement?

Event handlers are deleted after an error

Wow! This is totally unexpected. However it explains the behavior I see.

The man page says chan specifically but I assume it applies equally to sockets, pipes, file open's, etc. as well where one can assign an event handler?

Is there a way to log that problematic error message? Is there a proper
way to manage this apart from putting catch everywhere?

And thanks!

Yes, a channel read fileevent:

- catches any i/o command and closes the channel on failure
- first checks "fconfigure error" for sockets
- then invokes read or gets
- then checks eof (which is set by reads/gets)

Take care,
Harald
--- Synchronet 3.22a-Linux NewsLink 1.2