Exceptions in tk after procs?

ruby-talk
1

Hello,

There are a few situations when ruby code runs in a way that the raised
exceptions are swallowed by the ruby/tk code (I suppose). I didn’t look
much after it, but one of this is when ruby code runs as an 'after’
callback.

Can I somehow globally catch these exceptions? Because if I forget to
place a begin…rescue…TkDialog envelope to the code, these exceptions
are easily overlooked.

Thanks:
Ferenc

2

Hi,

···

From: Ferenc Engard ferenc@engard.hu
Subject: exceptions in tk after procs?
Date: Wed, 26 Nov 2003 08:00:13 +0900
Message-ID: 3FC3DF06.E675F7EB@engard.hu

There are a few situations when ruby code runs in a way that the raised
exceptions are swallowed by the ruby/tk code (I suppose). I didn’t look
much after it, but one of this is when ruby code runs as an ‘after’
callback.

TkAfter had a bug on treatment of TkAfter#cancel_on_exception=(mode).
I fixed it on CVS.
If you set TkAfter#cancel_on_exception = false, Tk will show an error
dialog box when the after callback cause an exception.
The default value of cancel_on_exception is true.
Then, the TkAfter object stops in silence when cause an exception.
On the same commitment to fix the bug, the instance variable
“@return_value” keeps the exception. And you can receive the
exception by TkAfter#wait method.

                              Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
3

There are a few situations when ruby code runs in a way that the raised
exceptions are swallowed by the ruby/tk code (I suppose). I didn’t look
much after it, but one of this is when ruby code runs as an ‘after’
callback.

TkAfter had a bug on treatment of TkAfter#cancel_on_exception=(mode).
I fixed it on CVS.
If you set TkAfter#cancel_on_exception = false, Tk will show an error
dialog box when the after callback cause an exception.
The default value of cancel_on_exception is true.

Why? :slight_smile:

Why should an uncatched exception be quiet? I think that is a
programming error, more often than not. Although, I mostly use TkAfter
for ‘after idle’, not for repeating tasks, so it is possible that this
alters my point of view.

Thanks for the bugfix.

Ferenc

4

Hi,

···

From: Ferenc Engard ferenc@engard.hu
Subject: Re: exceptions in tk after procs?
Date: Sun, 30 Nov 2003 03:29:30 +0900
Message-ID: 3FC8E580.AC9AF707@engard.hu

Why should an uncatched exception be quiet? I think that is a
programming error, more often than not.

Similar to threads.
For example, when you use a TkAfter object to blink a label text,
aren’t you glad that you need not worry about the TkAfter object
at destroying the label widget?

Although, I mostly use TkAfter
for ‘after idle’, not for repeating tasks, so it is possible that this
alters my point of view.

For ‘after idle’ only, there is ‘Tk.after_idle’ method.
It will show an error dialog, when its callback procedure causes an
exception.

                              Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
5

For ‘after idle’ only, there is ‘Tk.after_idle’ method.
It will show an error dialog, when its callback procedure causes an
exception.

And what about, say, TkEntry’s validatecommand functions? It seems that
they work similarly, i.e. discarding the exceptions. (I am not sure
about it right now, but I have a strong suspect. :slight_smile:

Ferenc

6

Oh, I have missed the TkCore’s after and after_idle methods. Why did I
suck with the understanding of the overcomplicated TkAfter class…?

I will test if this is good to me. Thanks!

Ferenc

Hidetoshi NAGAI wrote:

···

For ‘after idle’ only, there is ‘Tk.after_idle’ method.
It will show an error dialog, when its callback procedure causes an
exception.

7

Hi,

···

From: Ferenc Engard ferenc@engard.hu
Subject: Re: exceptions in tk after procs?
Date: Sun, 30 Nov 2003 23:34:51 +0900
Message-ID: 3FCA000E.F9CB843C@engard.hu

And what about, say, TkEntry’s validatecommand functions? It seems that
they work similarly, i.e. discarding the exceptions.

Which version of tcltklib do you use?
CVS HEAD version seems to catch the exception on validatecommand and
to show a dialog box.

                              Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)