Best way of error handling in TCL
sarathy
Currently i have to deal with quite a lot of TCL code.
What is the best way to handle errors extensibly in TCL? Putting a "set
a [ catch {} ] " fills most part of my code !!! Is there better error
code handling ???
Sarathy
Rob
From what I've seen the 'catch' approach is the standard way to catch errors
in tcl. Following the lead from code written by far more experienced tcl
programmers, I have started to use a common error handling proc to avoid
the issues associated with having catch command handling all over the place
(as you have found). From my experience with this common catch/error
handling proc is that it greatly simplifies overall coding.
Such a proc could contain the general purpose catch and then maybe generate
a return code to the calling code so that a specific error message is
generated or specific handling can be carried out within that general error
handling routine.
HTH
Rob.
Earl Greida
"sarathy" <sps.s...@gmail.com> wrote in message
news:1167807419.0...@s34g2000cwa.googlegroups.com...
Personally, I like "catch". It has been a lifesaver. What would you
consider a better method to be?
suchenwi
Earl Greida schrieb:
> Personally, I like "catch". It has been a lifesaver. What would you
> consider a better method to be?
My typical method is not to use catch. Code defensively to avoid
obvious mistakes, but Tcl and Tk's error handling is generally so good
that I can't think of a better way.
Oh, one thing, of course: a Tcl script writing to stdout, which is
piped through a filter like head or more, throws an error if the pipe
is closed early. Therefore I often code this one-liner:
proc puts! str {if [catch {puts $str}] exit}
Robert Heller
>
>
> Earl Greida schrieb:
>
> > Personally, I like "catch". It has been a lifesaver. What would you
> > consider a better method to be?
>
> My typical method is not to use catch. Code defensively to avoid
> obvious mistakes, but Tcl and Tk's error handling is generally so good
> that I can't think of a better way.
One *minor* nit: Tcl's 'open' always throws an error when there is a
problem, so one needs to use catch to handle file open problems
(sometimes you get a bad file name from user input and want to deal
with it effectively). So my file open code generally looks like:
if {[catch [list open "$filename" r] ifp]} {
tk_messageBox -type ok -icon error "Could not open $filename: $ifp"
return
}
>
> Oh, one thing, of course: a Tcl script writing to stdout, which is
> piped through a filter like head or more, throws an error if the pipe
> is closed early. Therefore I often code this one-liner:
>
> proc puts! str {if [catch {puts $str}] exit}
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
suchenwi
Robert Heller schrieb:
> One *minor* nit: Tcl's 'open' always throws an error when there is a
> problem, so one needs to use catch to handle file open problems
> (sometimes you get a bad file name from user input and want to deal
> with it effectively). So my file open code generally looks like:
>
> if {[catch [list open "$filename" r] ifp]} {
> tk_messageBox -type ok -icon error "Could not open $filename: $ifp"
> return
> }
But isn't that very close to the behavior when not catching the [open]
- you get a bgerror with a similar message
couldn't open "foo.bar": no such file or directory
while executing
"open foo.bar"
invoked from within
"set fp [open foo.bar]"
(command bound to event)
, and can click OK to get back to the event loop? On Windows at least.
Donal K. Fellows
> if {[catch [list open "$filename" r] ifp]} {
> tk_messageBox -type ok -icon error "Could not open $filename: $ifp"
> return
> }
That [catch] is still a bit complicated (the use of [list] isn't helping
at all) and the code above does not demonstrate why it is superior to
the default error handling. Try this out for size instead:
if {[catch {open $filename r} ifp]] then {
tk_messageBox -type ok -icon error -message \
[msgcat::mc "Could not open vital file %s: %s" $filename $ifp]
return
}
Donal.
Glenn Jackman
> One *minor* nit: Tcl's 'open' always throws an error when there is a
> problem, so one needs to use catch to handle file open problems
> (sometimes you get a bad file name from user input and want to deal
> with it effectively). So my file open code generally looks like:
>
> if {[catch [list open "$filename" r] ifp]} {
> tk_messageBox -type ok -icon error "Could not open $filename: $ifp"
> return
> }
Extremely minor nitpick: a matter of style. I would write that [catch]
statements like this:
if {[catch {open $filename r} ifp] != 0} {
#...
}
[catch] takes a script as it's first argument, so enclosing it in braces
is OK (just like [if] and [proc]). Variables will be evaluated in the
right scope. Using braces also lets you pass a multi-line script to
[catch] if you want to use it like Java's try:
set ret [catch {
cmd1
cmd2
cmd3
} output]
It's not necessary to quote variables in Tcl -- unlike shell scripting.
[catch]'s return value is an integer where 0 is success and other values
indicate errors and other conditions. I prefer to not use an integer as
a boolean value -- I try not to code Tcl like C.
--
Glenn Jackman
Ulterior Designer
Robert Heller
No, clicking OK exits Tcl/Tk (at least on UNIX). I guess it depends on
how bgerror is defined. Some of the time, the open is deep in some
procedure, which I want to return cleanly and let the calling proc
continue. In any case I *don't* want to confuse the end user with a Tcl
style error, complete with stack traces and such, I just want to tell
him/her that I could not open the file and a *brief* reason why (file not
found, permission denied, no such directory, etc.) and then bascially
continue with the application.
Michael Schlenker
primitive operation you use.
Depending on your app you may like to have your own control structures,
for example something like the sqlite api for transactions, which do
automatic rollback in case of errors, or callbacks when an error occurs
in your code or thousands of other clever ways.
One example would be the trycatch package
http://www.wjduquette.com/tcl/trycatch.html
Michael