Prev: TclOO: Can I execute a method from an object in the context ofanother object?
Next: attribute lookup and replace
From: Don Porter on 13 Apr 2010 13:05
cattaghia wrote:
> What I'm thinking about would be something close to Larry's second
> thought. For event/background errors, we have ::bgerror. For procedure
> calls which don't match any command, we can override ::unknown. Isn't
> it possible to have a procedure called when a "common" error happens
> and is uncatched until the global scope?

Unless I'm missing something, this scenario boils down to one of
the Tcl_*Eval*() routines returning a code other than TCL_OK. Why
would a caller of such a routine not be checking the return code?

It seems to me the answer is "Don't Do That" as in don't call a routine
to evaluate a Tcl script and then fail to check whether it succeeded.

--
| Don Porter Mathematical and Computational Sciences Division |
| donald.porter(a)nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
From: Helmut Giese on 13 Apr 2010 13:28
Hi,
>Helmut, what I know about bgerror is exactly that a procedure with
>such name can be created and automatically called for handling those
>errors which happen due to events, like the button press you
>mentioned.
if you target Tcl 8.5 read Tcl's man page on bgerror: There is a new
possibility to register an error handler with any interpreter (interp
bgerror).

You probably will have to experiment a little: The above mentioned man
page mentions this new option but then mostly describes the old
mechanism - for people wanting to be backwards compatible.

The interpreter man page adds a tiny bit of information - but I know,
that _I_ would have to experiment to get it straight. All in all,
however, it seems to be just what you are looking for.
Good luck
Helmut Giese

From: cattaghia on 13 Apr 2010 19:33
Yeah I agree, Don, but, like I said, this would be useful in a
scenario where really unexpected errors could happen. For example,
when your application sources a script which was not written by
yourself, and you can not assure that it uses "catch" appropriately
all the time, or any other buggy thing (and you´re not running the
script in another interp).

bgerror was mentioned just as a parallel; I was just reading about
"interp bgerror" two days ago and it is not really what I am talking
about because it deals with background errors, not the "common" errors
we usually catch.
From: Larry W. Virden on 14 Apr 2010 06:51
On Apr 13, 7:33 pm, cattaghia <cattag...(a)ig.com.br> wrote:
> [...] and it is not really what I am talking
> about

The best next step would be to provide a small coherent example of the
problem you are trying to solve, so that people can provide to you
specific coding techniques to deal with the situation.

I would pretty much guarantee the examples provided will use catch or
try or bgerror
From: Don Porter on 14 Apr 2010 08:12
cattaghia wrote:
> Yeah I agree, Don, but, like I said, this would be useful in a
> scenario where really unexpected errors could happen. For example,
> when your application sources a script which was not written by
> yourself, and you can not assure that it uses "catch" appropriately
> all the time, or any other buggy thing (and you�re not running the
> script in another interp).

So, is it [source] that is the bad actor?

--
| Don Porter Mathematical and Computational Sciences Division |
| donald.porter(a)nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: TclOO: Can I execute a method from an object in the context ofanother object?
Next: attribute lookup and replace