[ 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