"catch { } around everything" - improvement suggestion

[ZB]

I've found it on the Erlang wiki-page http://wiki.tcl.tk/8966: "Handle
errors in a higher layer -- Interesting... Don't waste valuable processing
time wrapping catch { } around everything. Handle it in a separate
(controlling) thread that is signaled with the error".

Yes, it seems to be obvious: couldn't be a mechanism introduced to "catch
globally" (I mean: every error)? The current behaviour is very good for
debugging purposes - but for application "nothing like `catch' ". Bash has
its "set -e" (which is analogous to Tcl's default) - why not introduce such
global switch in Tcl?
--
ZB

[Ron Fox]

catch {source myapplication.tcl} ...

:-D

[ZB]

Dnia 10.10.2007 Ron Fox <f...@nscl.msu.edu> napisał/a:

> catch {source myapplication.tcl} ...
>
>:-D

:-O
--
ZB

[Twylite]

> Yes, it seems to be obvious: couldn't be a mechanism introduced to "catch
> globally" (I mean: every error)? The current behaviour is very good for
> debugging purposes - but for application "nothing like `catch' ". Bash has
> its "set -e" (which is analogous to Tcl's default) - why not introduce such
> global switch in Tcl?

bgerror and interp bgerror?

Then put the main body of your script (anything not in a proc) in an
"after 0" handler.

Twylite

[Uwe Klein]

Having exception handling like the 680x0 Motorola CPUs would be nice.
i.e.
write to socket
error!
<exception called>
clean up your act
if not possible
end execution
<exception return>
continue
with code after write.
as if nothings happened.

uwe

[Cameron Laird]

In article <slrnfgpfik.9j3...@sarge.my.own.domain.no-net>,

Let's make this explicit: one common and oft-recommended
style for source composition looks something like this:

proc main {} {
...
}

proc one_proc args {...}
proc other_proc args {...}

main

Notice how readily this transforms to

proc main {} {
...
}

proc one_proc args {...}
proc other_proc args {...}

if [catch main top_level_result] {deal_with $top_level_result}

[ZB]

Dnia 10.10.2007 Cameron Laird <cla...@lairds.us> napisał/a:

> Let's make this explicit: one common and oft-recommended
> style for source composition looks something like this:
>
> proc main {} {
> ...
> }

Yes, indeed - you're right. Perhaps it's the strongest argument for having
"main" in the program body.
--
ZB

[tom.rmadilo]

Here is the meaning of catch in certain instances:

catch { code so unimportant, don't even tell me if it fails}

if [catch {stuff I'd really like to do}] { but I'll settle for this}

if {[catch {important code which might fail} err]} {
code to clean up from failure
recall the error with additional info
}

But Tcl 8.5 makes it a little easier to use catch, so the details of
when, where and why of catch make it impossible to give generic
advice. But in general, catch is a part of an overall plan, it isn't
really a full command where you can judge correct/incorrect from a
small section of code. It does seem to me that if you slap a catch
around code just because you are not sure if it will return an error,
this falls into the category of not really caring about the wrapped
code. I was creating an email filter today, and in choosing the
directory I was offered a button to create a new directory. Click.
Nothing. Click again. Nothing. This is essentially what catch all by
itself achieves: silent failure. If silent failure is the intended
purpose of the catch, then this is okay.

[ZB]

Dnia 10.10.2007 tom.rmadilo <tom.r...@gmail.com> napisał/a:

> If silent failure is the intended purpose of the catch, then this is okay.

Not quite. I would just to avoid usual alarming style of error messages -
and instead of this to place on the screen some kind of more calm-looking
information, something a'la Microsofts error-message style: "Something
strange did happen - send a report to manufacturer..." or similar.

The usual error messages of course are very helpful during design and
beta-testing stage - but in the final "V1.0" version it would look a bit too
worrisome for the end-user.
--
ZB