TIP #89: Try/Catch Exception Handling in the Core
Tom Wilkason
TIP #89: TRY/CATCH EXCEPTION HANDLING IN THE CORE
===================================================
Version: $Revision: 1.1 $
Author: Tom Wilkason <tom.wilkason_at_cox.net>
Frank Pilhofer <520065607613-0001_at_t-online.de>
State: Draft
Type: Project
Tcl-Version: 8.4
Vote: Pending
Created: Monday, 11 March 2002
URL: http://purl.org/tcl/tip/89.html
WebEdit: http://purl.org/tcl/tip/edit/89
Discussions-To: news:comp.lang.tcl
Post-History:
-------------------------------------------------------------------------
ABSTRACT
==========
This TIP proposes the addition of a _try_..._catch_..._finally_ command
to provide a more robust and powerful exception handling mechanism.
RATIONALE
===========
Exceptions are currently supported very well in Tcl, in fact they are a
major advantage over many other languages. However the mechanism to
_catch_ and handle the errors is someone limited and does not promote
the full use of existing error codes. Wrapper procedures can be written
to improve on this, however both a performance and compatibility
penalty is incurred.
This TIP proposes adding a try/catch command to the Tcl core, not
unlike those found in C++, C#, Java and Python (to name a few).
SPECIFICATION
===============
I propose the following two commands be added to Tcl:
_throw_ statement
throw ?<type> ?<message>??
A _throw_ statement with _type_ throws an error exception with
the errorCode _type_. The _throw_ statement works as the _error_
statement, but the arguments are reordered to encourage the use
of errorCodes.
The throw _type_ is that set in errorCode, any user defined type,
built-in types include POSIX, ARITH, CORE, REGEXP, WINDOWS ,
NONE, ... The message is optional, and is the same as that issued
by the catch command, error -code error "message"
An instance of _throw_ with no arguments can be used within a
_catch_ or _finally_ block to immediately re-throw the current
exception that is being handled by the _catch_ block. When an
error is re-thrown in the catch block, the current error is
propagated up one level following the evaluation of the _finally_
block (if on exists). If the error is re-thrown in a _finally_
block, the error is immediately propagated up one level. When an
exception is re-thrown, control is transferred to the first
_catch_ clause in an enclosing _try_ statement that can handle
the exception.
throw type message
is the same as
error message "" type
_try_ statement
try body ?catch {type ?var?} body ...? ?finally body?"
If a one or more _catch_ blocks are specified, each corresponding
_body_ represents a required block of code that is evaluated if
the resulting errorCode matches the _type_ condition. The
required body of the _finally_ block is evaluated following the
_try_ block and _catch_ block.
If no _catch_ blocks are specified, the error is ignored with
execution immediately resuming at the start of the _finally_
block (if specified).
_type_ represents the errorCode and can be matched using glob
style matching, if _var_ is specified the current error message
will be placed in it in the local scope upon a errorCode match.
Note, _catch_, if specified, will catch all remaining errors. If
used, it should be placed last since each of the catch blocks are
evaluated in order. _type_ is that set in errorCode, and can be
any user defined type, or built-in types including POSIX*,
ARITH*, CHILD*, CORE, REGEXP, WINDOWS, or NONE.
If one or more _catch_ blocks are specified, and no _catch_ block
matches the errorCode condition, the error will be propagated up
to the next level following evaluation of the _finally_ clause
(if specified). An enclosing _try_ block (or _catch_ command) can
then be used handle the error.
_message_ is the same as that issued by the _catch_ command or
returned with
error -code error "message"
The _finally_ block is used to perform all the clean up code. The
_finally_ body is evaluated whether the error occurs or not, or
if a _catch_ block matched the errorCode. It is also evaluated if
a _throw_ statement occurs within the _catch_ clause.
EXAMPLES
==========
_throw_
throw DEVICE "Could not write to device"
'try_ only (no practical use)
try {
incr i
}
_try - catch _
try {
incr i
} catch {*} {
set i 0
}
_try - finally _
try {
. config -cursor watch
#do some busy stuff here, don't care about errors
} finally {
. config -cursor arrow
}
_try - catch - catch _
try {
;# Some code that will cause an error
} catch {"POSIX*" result} {
;# Statements to handle POSIX type errors
} catch {NULL result} {
;# Statements to handle NULL (a user created) type errors
} catch {* result} {
;# Statements to handle all other errors
}
_try - catch - catch - finally _
try {
;# Some code that will cause an error
} catch {"POSIX*" result} {
;# Statements to handle POSIX type errors
} catch {* result} {
;# Statements to handle all other errors
} finally {
;# Statements to execute whether an error occurred or not
}
Re-throw _try - catch - finally _
try {
try {
set b [expr {$a/0}]
} catch {ARITH*} {
if {$a == 0} {
throw ;# re-throw to outer try
}
} finally {
set b 1 ;# will execute before throw above
}
} catch {ARITH* result} {
;# This will catch the inner throw
puts "$res"
}
REFERENCE IMPLEMENTATION
==========================
This implementation is based on Frank Pilhofer's _combat:try_ which is
part of the Tcl Combat/Corba extension. Glob style match typing has
been added and the nested throws have been added ala C#.
COPYRIGHT
===========
This document has been placed in the public domain.
-------------------------------------------------------------------------
TIP AutoGenerator - written by Donal K. Fellows
[[Send Tcl/Tk announcements to tcl-an...@mitchell.org
Send administrivia to tcl-announ...@mitchell.org
Announcements archived at http://groups.yahoo.com/group/tcl_announce/
The primary Tcl/Tk archive is ftp://ftp.neosoft.com/pub/tcl/ ]]
Darren New
> This TIP proposes adding a try/catch command to the Tcl core, not
> unlike those found in C++, C#, Java and Python (to name a few).
What about [return -code return], break, continue, and [return -code
382]?
I would suggest that if such a code is thrown, the <type> reflect it, so
as to unify the processing.
try {
blah blah
} catch {BREAK result} {
exit the loop
} catch {CONTINUE result} {
skip to next iteration
} catch {387 result} {
weird stuff here
} finally {
close file handles
}
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
Remember, drive defensively if you drink.
Donal K. Fellows
> What about [return -code return], break, continue, and [return -code
> 382]? I would suggest that if such a code is thrown, the <type> reflect
> it, so as to unify the processing.
*I* would suggest that it should *not* be possible to use [try] to trap
[return], [break] or [continue] signals. Just error conditions, with matching
against $::errorCode which ought to be used by more people (me included.)
Nobody's suggesting getting rid of [catch], which is a more primitive operation,
just as the existence of [global] and [variable] does not mean that there is no
need for [upvar].
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- Maybe we should do cultural exchange and rename those languages _Smltk and
ThirdLetterOfAlphabet. -- Mark van Gulik <gho...@home.net>
Frank Pilhofer
> Tom Wilkason wrote:
> > This TIP proposes adding a try/catch command to the Tcl core, not
> > unlike those found in C++, C#, Java and Python (to name a few).
>
> What about [return -code return], break, continue, and [return -code
> 382]?
>
> I would suggest that if such a code is thrown, the <type> reflect it, so
> as to unify the processing.
>
I don't think so. The catch {} clause operates on the errorCode, not the
completion code.
According to the manual page of return, errorCode defaults to NONE, so
you'd be able to catch that. If the user wants to handle other completion
codes, then the user should use return's -errorcode option.
Frank
--
Frank Pilhofer ........................................... f...@fpx.de
Adolescence is that period in a child's life when parents become
most difficult! - Alfred E. Neuman
Neil Madden
>
> Darren New wrote:
> > What about [return -code return], break, continue, and [return -code
> > 382]? I would suggest that if such a code is thrown, the <type> reflect
> > it, so as to unify the processing.
>
> *I* would suggest that it should *not* be possible to use [try] to trap
> [return], [break] or [continue] signals.
Hmm - why? [catch] currently catches all of these. Presumably, they would only
be caught if there was a catch block referring to them, otherwise they would be
propagated up to the next level. Something like:
foreach item $list {
try {
continue
} catch {SOME_ERROR} {
# blah
}
}
as there is no explicit catch block for "continue", then it works as expected.
Being able to catch other return codes than TCL_ERROR would be very useful, IMHO
- especially when creating your own exception types (with their own return
code).
> Just error conditions, with matching
> against $::errorCode which ought to be used by more people (me included.)
How should one use ::errorCode? I have just done some quick experiments, and
looked at ::errorCode after various errors, and I'm slightly baffled by the
words that appear in it. Is there some place that defines what errorCode will
hold from various types of error? If I was using a try-catch construct to catch
errors, I'd want the pattern to look for to be obvious, for instance, when
seeing if an [open] command failed because a file doesn't exist, looking for
POSIX ENOENT is not the first thing that springs to my mind, but then I'm not
familiar with POSIX error codes (I assume that's what this is).
>
> Donal.
> --
--
package r Tkhtml;package r http;pack [scrollbar .v -o v -co {.h yv}] -s right\
-f y;pack [html .h -ys {.v set}] -f both -e 1;bind .h.x <1> {eval g [.h href %x\
%y]};proc g u {set t [http::geturl $u];.h cl;.h p [http::data $t];http::cleanup\
$t;.h co -base $u};g http://mini.net/tcl/976.html;proc bgerror args {};# NEM :-)
Frank Pilhofer
>
> How should one use ::errorCode? I have just done some quick experiments, and
> looked at ::errorCode after various errors, and I'm slightly baffled by the
> words that appear in it. Is there some place that defines what errorCode will
> hold from various types of error?
>
Yes; have a look at the tclvars manual page.
But the try {} catch construct will not be limited to these; in fact, it
should encourage the user to extend that scheme and to create "exception
types" that make sense to her - errorCode would then be the vehicle to trans-
port these "user exceptions".
Donal K. Fellows
> But the try {} catch construct will not be limited to these; in fact, it
> should encourage the user to extend that scheme and to create "exception
> types" that make sense to her - errorCode would then be the vehicle to trans-
> port these "user exceptions".
I've used errorCode (combined with a custom [bgerror]) in the past to mark some
errors as being suitable to ignore silently, and others as being ones to howl
about. And I thought this message was going to be a lot more relevant than it
turned out...
Neil Madden
>
> Neil Madden <nem...@cs.nott.ac.uk> wrote:
> >
> > How should one use ::errorCode? I have just done some quick experiments, and
> > looked at ::errorCode after various errors, and I'm slightly baffled by the
> > words that appear in it. Is there some place that defines what errorCode will
> > hold from various types of error?
> >
>
> Yes; have a look at the tclvars manual page.
>
> But the try {} catch construct will not be limited to these; in fact, it
> should encourage the user to extend that scheme and to create "exception
> types" that make sense to her - errorCode would then be the vehicle to trans-
> port these "user exceptions".
Ah - that sounds good. One final point: I quite like Java's OO exceptions where
the exception itself is an object which can contain additional information about
what went wrong. Under this scheme, could I create an Itcl object (or XOTcl,
or...) and store it's name in errorCode somehow so that I could operate on it in
the catch block?
>
> Frank
>
> --
> Frank Pilhofer ........................................... f...@fpx.de
> Adolescence is that period in a child's life when parents become
> most difficult! - Alfred E. Neuman
Don Porter
> One final point: I quite like Java's OO exceptions where
> the exception itself is an object which can contain additional information
> about what went wrong. Under this scheme, could I create an Itcl object
> (or XOTcl, or...) and store it's name in errorCode somehow so that I could
> operate on it in the catch block?
This begins to get into conventions for how to interpret the ::errorCode
value. That is strictly speaking outside the scope of the [try]
specification, but still a good thing to discuss.
::errorCode must hold a list. The interpretation of the elements of
that list are unspecified, so different programmers can invent different
approaches.
I think it is best to use the first word of ::errorCode to hold the name
of a particular scheme for interpreting the remaining words. If you
like Java-style exceptions, you might use the key word JAVA as the first
word of ::errorCode to indicate that style. Then, in that scheme, the
next word might be the command (object) that is the exception.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Neil Madden
>
> Neil Madden wrote:
> > One final point: I quite like Java's OO exceptions where
> > the exception itself is an object which can contain additional information
> > about what went wrong. Under this scheme, could I create an Itcl object
> > (or XOTcl, or...) and store it's name in errorCode somehow so that I could
> > operate on it in the catch block?
>
> This begins to get into conventions for how to interpret the ::errorCode
> value. That is strictly speaking outside the scope of the [try]
> specification, but still a good thing to discuss.
>
> ::errorCode must hold a list. The interpretation of the elements of
> that list are unspecified, so different programmers can invent different
> approaches.
>
> I think it is best to use the first word of ::errorCode to hold the name
> of a particular scheme for interpreting the remaining words. If you
> like Java-style exceptions, you might use the key word JAVA as the first
> word of ::errorCode to indicate that style. Then, in that scheme, the
> next word might be the command (object) that is the exception.
That's what I was thinking of. If I read the TIP correctly, something like this
should work:
proc mythrow {msg} {
set e [Exception #auto $msg]
throw JAVA $e
}
try {
mythrow "Something bad happened"
} catch {JAVA* ex} {
# Do something with the Itcl object in $ex
itcl::delete object $ex
}
Hmm.. This will look odd if the exception reaches the toplevel, as the user will
be presented with a weird message (the name of the Itcl object), if I read this
correctly. I could get around this by doing:
throw "JAVA $e" $msg
in the mythrow proc, and then parsing the exception name out of ::errorCode in
the catch block, but that seems messy from a programmer's point of view now. If
there was some way to tie in some extra information with an exception, this
would be better.
BTW - I am assuming that the variable specified in the catch gets filled out
with the message, and not the contents of ::errorCode. Is this correct?
Don Porter
> That's what I was thinking of. If I read the TIP correctly, something like
> this should work:
>
> proc mythrow {msg} {
> set e [Exception #auto $msg]
> throw JAVA $e
> }
good questions deleted...
> BTW - I am assuming that the variable specified in the catch gets filled out
> with the message, and not the contents of ::errorCode. Is this correct?k
The exact syntax of [throw] and [try] are still in flux. The original
TIP made one proposal. Comments have offered alternatives.
Tom Wilkason
news:3C92247B...@cs.nott.ac.uk...
| Don Porter wrote:
| >
<good stuff removed>
Based on other suggestions, the catch syntax could possibly allow you to grab not
only the message but optionally the remaining errorCode data (and errorInfo
variables) without resorting to use of magic variables. So you could do something
like:
proc mythrow {msg} {
set e [Exception #auto $msg]
throw [list JAVA $e] $msg ;# complete errorCode is a list
}
try {
mythrow "Something bad happened"
} catch {JAVA* ex msg} {
# ex holds the remaining errorCode elements,
# which we know to be the object handle in this case
# Maybe log or tell user something with $msg
# Do something with the Itcl object in $ex
itcl::delete object $ex
}
Greate use cases such as will surely help solidify the syntax.
--
Tom Wilkason
Frank Pilhofer
>
> That's what I was thinking of. If I read the TIP correctly, something like
> this should work:
>
> proc mythrow {msg} {
> set e [Exception #auto $msg]
> throw JAVA $e
> }
>
> user will be presented with a weird message (the name of the Itcl object),
> if I read this correctly.
>
It's messy already if you let errors propagate to the toplevel and display
them to the user.
But this could be done much less messily if you define a proper bgerror
(which is where the exception would ultimately pop up).
Frank
--
Frank Pilhofer ........................................... f...@fpx.de
An argument is two people trying to get the last word in first.
- Alfred E. Neuman
Don Porter
>> Hmm.. This will look odd if the exception reaches the toplevel, as the
>> user will be presented with a weird message (the name of the Itcl object),
>> if I read this correctly.
> It's messy already if you let errors propagate to the toplevel and display
> them to the user.
It's important to keep distinct the parts of Tcl's error system meant
to be human-readable, error messages and ::errorInfo, and that part
meant for program control, ::errorCode.
[throw] and [try] are about putting friendlier interfaces around
::errorCode. They should have little impact on the messages presented
to the user.
Darren New
>
> Darren New <dn...@san.rr.com> wrote:
> > Tom Wilkason wrote:
> > > This TIP proposes adding a try/catch command to the Tcl core, not
> > > unlike those found in C++, C#, Java and Python (to name a few).
> >
> > What about [return -code return], break, continue, and [return -code
> > 382]?
> >
> > I would suggest that if such a code is thrown, the <type> reflect it, so
> > as to unify the processing.
> >
>
> I don't think so. The catch {} clause operates on the errorCode, not the
> completion code.
I don't understand what you mean by "operates on". Catch doesn't operate
on anything. It calls the first argument, it puts the return value in
the second argument and the return -code is returned as catch's value.
> According to the manual page of return, errorCode defaults to NONE, so
> you'd be able to catch that. If the user wants to handle other completion
> codes, then the user should use return's -errorcode option.
OK, here's another example.
proc tcf {} {
try {
set f [open mumble]
return -code 35 $f
} finally {
close $f
}
}
set x [catch tcf]
Is mumble closed at this point? What's the value of x?
I'd suggest that the value of "x" be 35 and that mumble be closed. I
would also suggest that there be some way of dealing in the "catch" part
of "try/finally" for when the call to catch implicit in the "try" part
returns something other than 0 or 1. Figuring out how to deal with
breaks and continues when you're writing your own control structures
would be so much easier. (Of course, an example on the "catch" menu page
of the right way of dealing with break and continue and return would
also be very helpful.)
Frank Pilhofer
>
> proc tcf {} {
> try {
> set f [open mumble]
> return -code 35 $f
> } finally {
> close $f
> }
> }
>
> set x [catch tcf]
>
> Is mumble closed at this point? What's the value of x?
> I'd suggest that the value of "x" be 35 and that mumble be closed.
>
Right, that's how it should be. This is required so that you can call
break and continue from within a try {} block, which should be as trans-
parent to break, catch and return as an if statement.
>
> would also suggest that there be some way of dealing in the "catch" part
> of "try/finally" for when the call to catch implicit in the "try" part
> returns something other than 0 or 1.
>
No, I don't think so. If you need to do that, you should use the "-error-
code" option of return to provide an appropriate value to catch.
Mabe break and continue could be changed to provide meaningful values in
errorCode - then you'd be able to catch them appropriately.
Frank
--
Frank Pilhofer ........................................... f...@fpx.de
If at first you don't succeed ... you're about normal. - A. E. Neuman
Don Porter
>> would also suggest that there be some way of dealing in the "catch" part
>> of "try/finally" for when the call to catch implicit in the "try" part
>> returns something other than 0 or 1.
> No, I don't think so. If you need to do that, you should use the "-error-
> code" option of return to provide an appropriate value to catch.
I believe the -errorcode option is only active for [return -code error].
> Mabe break and continue could be changed to provide meaningful values in
> errorCode - then you'd be able to catch them appropriately.
No. [try] is only meant to be a nicer interface to managing ::errorCode
when handling a return code of TCL_ERROR. It's not supposed to replace
all functions of [catch].
Darren New
>
> Darren New <dn...@san.rr.com> wrote:
> >
> > proc tcf {} {
> > try {
> > set f [open mumble]
> > return -code 35 $f
> > } finally {
> > close $f
> > }
> > }
> >
> > set x [catch tcf]
> >
> > Is mumble closed at this point? What's the value of x?
> > I'd suggest that the value of "x" be 35 and that mumble be closed.
> >
>
> Right, that's how it should be. This is required so that you can call
> break and continue from within a try {} block, which should be as trans-
> parent to break, catch and return as an if statement.
Well, *I* would like this to work
try {
do something with uplevel perhaps
} break {
something said "break"
} continue {
something said "continue"
} catch {POSIX ... whatever} {
handle some other error
} finally {
always gets done
}
No new "keywords", easy to understand. If the error code isn't "break"
or "continue" then said break or continue gets passed upwards. That is,
if the "break" clause is left out, then the "break" gets passed upwards.
I don't see any good reason to leave out such handling, but someone else
might. It's pretty complicated to get (say) your own loop commands with
"catch".
Or, of course, putting examples in the documentation for "catch" would
help. :-) Is it on the Wiki anywhere?
Frank Pilhofer
>
> Well, *I* would like this to work
>
> try {
> do something with uplevel perhaps
> } break {
> something said "break"
> } continue {
> something said "continue"
> } catch {POSIX ... whatever} {
> handle some other error
> } finally {
> always gets done
> }
>
> might. It's pretty complicated to get (say) your own loop commands with
> "catch".
>
IMHO, catch {} should only look at the errorCode variable. After intro-
ducing try/catch, it should be discussed if it makes sense to make break
and continue assign meaningful values to errorCode, so that they can be
handled with try/catch. In the same discussion, we could also look at
whether it makes sense to allow `return -errorcode' for other return
codes than just `error'.
But making try/catch look at the combination of the return code and
errorCode sounds ugly to me. For try/catch, the return code should be
just a boolean value; 0 means "don't look at any of the catch clauses",
and anything else than 0 means "try to find some catch clause that
matches errorCode".
Frank
--
Frank Pilhofer ........................................... f...@fpx.de
How is it that people looking for a helping hand tend to overlook
the one at the end of their arm? - Alfred E. Neuman
Donal K. Fellows
> Well, *I* would like this to work
>
> try {
> do something with uplevel perhaps
> } break {
> something said "break"
> } continue {
> something said "continue"
> } catch {POSIX ... whatever} {
> handle some other error
> } finally {
> always gets done
> }
Good idea. I like it, though I might prefer:
try {
...
} catch break {
...
}
Sure, it is ambiguous, but also more consistent from another point of view;
we're not generating a [break] but rather catching one.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- What's the reason of long discussions, if at the end someone says, "we have
not yet thought about it..." -- Andreas Leitgeb <a...@pc7499.gud.siemens.at>
Darren New
> But making try/catch look at the combination of the return code and
> errorCode sounds ugly to me. For try/catch, the return code should be
> just a boolean value; 0 means "don't look at any of the catch clauses",
> and anything else than 0 means "try to find some catch clause that
> matches errorCode".
Well, I think that would be pretty confusing, since "break" returns
something other than 0, so your statement implies that try/catch should
always catch breaks and continues, but always fail to match them.. I'm
not sure why it is you make the assertion that "for try/catch, the
return code should be just a boolean value." Why? I'm not saying you're
wrong, I'm just saying that you haven't made clear why you feel that's
right.
*I* think it should be able to handle break and continue because it
unifies everything coming out of the [catch] that's implicitly called by
the [try], it makes try/catch work in more situations without having to
use naked [catch], and it works exactly the way you seem to want it to
work if you don't attempt to catch break or continue, so I don't see any
downside of including that. What do you think is the downside?
Thus spake Donal:
> } catch break {
> Sure, it is ambiguous, but also more consistent from another point of view;
> we're not generating a [break] but rather catching one.
Sure. That works better. I was just thinking that using the same
"keyword" would make it easier to understand. "catch break" makes even
better sense to me.
lvi...@yahoo.com
According to Darren New <dn...@san.rr.com>:
: I was just thinking that using the same
:"keyword" would make it easier to understand. "catch break" makes even
:better sense to me.
Ah, many of us never catch a break, so that would always fail...
--
"I know of vanishingly few people ... who choose to use ksh." "I'm a minority!"
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.