Prev: TclOO: Can I execute a method from an object in the context ofanother object?
Next: attribute lookup and replace
From: cattaghia on 12 Apr 2010 13:08
Hehe. Sorry if I used a wrong terminology, but I hope you understand
the question.

There are situations in which you can use "catch" through all of your
code, but there is still a chance -- for example, if your code sources
third-party scripts that might be buggy -- that an error goes
"uncatched" and unwinding up in the call stack until reaching the
interpreter itself. I am not sure if there could be enough "catch"es
for all the unexpected possibilities, that's it.

So, is there a way to set up the interpreter to do something else than
halt the script evaluation and display an error message when (and only
when) an error-raising sequence reaches the global scope? Maybe more
or less like bgerror does, if I know it enough. I guess that a "trace"
on ::errorCode would not work, because the variable would be modified
when the error really happened, prior to the stack unwinding...
From: Larry W. Virden on 13 Apr 2010 06:56
On Apr 12, 1:08 pm, cattaghia <cattag...(a)ig.com.br> wrote:

>
> So, is there a way to set up the interpreter to do something else than
> halt the script evaluation and display an error message when (and only
> when) an error-raising sequence reaches the global scope?

The first thing I thought of was to put the normally global part of
your application into a proc, so that what you execute at the global
level is a catch on that main procedure.

A second thought that occurred to me was wondering whether there was a
way to rename the error handling routine and then creating a new proc
of the same name that worked the way you wanted.
From: Arjen Markus on 13 Apr 2010 07:47
On 12 apr, 19:08, cattaghia <cattag...(a)ig.com.br> wrote:
> Hehe. Sorry if I used a wrong terminology, but I hope you understand
> the question.
>
> There are situations in which you can use "catch" through all of your
> code, but there is still a chance -- for example, if your code sources
> third-party scripts that might be buggy -- that an error goes
> "uncatched" and unwinding up in the call stack until reaching the
> interpreter itself. I am not sure if there could be enough "catch"es
> for all the unexpected possibilities, that's it.
>
> So, is there a way to set up the interpreter to do something else than
> halt the script evaluation and display an error message when (and only
> when) an error-raising sequence reaches the global scope? Maybe more
> or less like bgerror does, if I know it enough. I guess that a "trace"
> on ::errorCode would not work, because the variable would be modified
> when the error really happened, prior to the stack unwinding...

Could you be a bit more specific about what you want it to do?
Perhaps using some pseudocode? After all, in many cases, there is
little
else you can do than print an error message.

Regards,

Arjen
From: Helmut Giese on 13 Apr 2010 07:56
Hi,
>So, is there a way to set up the interpreter to do something else than
>halt the script evaluation and display an error message when (and only
>when) an error-raising sequence reaches the global scope? Maybe more
>or less like bgerror does, if I know it enough. I guess that a "trace"
>on ::errorCode would not work, because the variable would be modified
>when the error really happened, prior to the stack unwinding...
I don't think you can reliably catch everything:
- Event handlers run at global scope and if a proc bound to a button
press contains an error - boom.
- Worse even, just _invoking_ an event handler can produce an error,
because of a typo (wron name of proc) or wrong number of arguments.

However, IIRC you can write your own version of bgerror where you can
do anything you want. Look in Tcl's help under bgerror.

HTH
Helmut Giese
From: cattaghia on 13 Apr 2010 12:54
Hi all, thanks for the attention!

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.

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?

This would be useful, for example, when a script is running under Wish
and we don't want the program to abort and show an error message in a
console window. A designated procedure could then display the error
message in a tk_messageBox, or in a status bar in the main window, for
example.

I know very little about the Tcl internals and I don't know what
happens when an uncatched error goes up to the global scope. But maybe
a mechanism like this could work as unknown and bgerror. Something
like:

# Error happens, nothing catches it
# Error reaches global scope
# Was a procedure designated for treating such cases?
# YES: Call the proc. It does what it wants and returns 1 if
everything was fine, 0 if it could not do what it wanted. If an error
happens in itself, we will consider it as a 0 returned.
# If the proc returned 1, ok, forget the error
# If the proc returned 0 or had an error itself, show the error in
stderr and terminate the script
# NO: Show the error in stderr and terminate the script

Maybe this could become a TIP someday, I don't know... I am trying to
write an error handling system for a project of mine, more or less in
these lines (and I'm trying to make it as general and reusable as
possible, so I hope I can post it in the wiki soon), but while this
system can create bgerror and unknown procedures for showing
convenient dialogs, common errors still depend on a procedure
"catching" the error and passing it to the dialog-building routines...

Thank you once again!

Fabricio Rocha
Brasilia, Brasil
 |  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