[ Home ]
[ Authors ]
[ Index ]
[ Abbreviations ]
[ Bindings ]
Error Handling
Errors in scripts, procedures, and methods should be handled simply
by calling the
error procedure,
which is built into Tcl. The single argument is an error message.
This procedure unravels the stack (so you do not need to return
after calling it). If the error occurs in the background (most
errors are
background errors, since Tycho
applications are interactive, and most procedures are invoked in
response to key or mouse bindings), then the error procedure calls
the tkerror procedure.
This procedure is defined by Tycho
in the global scope, rather than the "tycho" scope.
Thus, if I trigger an error as follows:
error {Error message}
Tcl believes that an error occurred trying to run the Tcl script
embedded in this text. If you click on the "Stack Trace" button
that appears in error message box,
you can verify that the error occurred within a call of the form
"uplevel #0 $cmd". This is, in fact, the statement that executes
embedded Tcl code in this document. The Tcl code you just executed
triggered an error.
The stack trace
generally reflects information about the most recent
error that generated a stack trace. Thus, if you invoke the "tkerror"
script directly the stack trace will be
fairly meaningless, if there is one at all. The correct way to
signal an error within your own scripts by calling error, not tkerror.
Copyright © 1996, The Regents of the University of California.
All rights reserved.
Last updated: 96/04/09,
comments to: eal@eecs.berkeley.edu