if 0 {[Richard Suchenwirth] 2003-07-29 - [Error]s happen, and in Tcl they're less depressing and more educational than in most other languages. Also, one can try things like resuming at the position where the error happened - almost. Consider this code, where [error] is renamed into the Tcl namespace}

 rename error tcl::error
if 0 {and redefined to a simple interactive prompt, where you can check what went wrong, maybe fix it, and decide to "c"ontinue or keep the error ("x"):
}
 proc error {code args} {
    puts $code/$args
    while 1 {
        puts -nonewline "% "
	flush stdout
	gets stdin line
	if {$line=="x"} {tcl::error $::errorCode}
	if {$line=="c"} break
	catch {uplevel 1 $line} res
	puts $line
    }
 }
if 0 {The test code is heavily [puts]y so one sees what goes on, and does two deliberate errors in the "try" proc: one by just calling an error, one by referencing a undefined variable.
 puts "before try"
 proc try {} {
    puts "in try"
    error intended
    puts x=$x
    puts "after error"
 }
 try
 puts "after try"
if 0 {Experimenting with this, I find the intended error triggers indeed, and lets me fix the missing x bug, and resume:

 suchenwi@jaguar% tclsh error2.tcl                                       
 before try
 in try
 intended/
 % set x hello ;# fix the missing x variable bug "on the fly"
 hello
 % c
 x=hello
 after error
 after try

but if I just let the intended error resume, missing x appears to be hard-wired to the original [error], not my overloaded version:
 suchenwi@jaguar% tclsh error2.tcl                                         
 before try
 in try
 intended/
 % c ;# continue without fixing
 can't read "x": no such variable
    while executing
 "puts x=$x"
    (procedure "try" line 4)
    invoked from within
 "try"
    (file "error2.tcl" line 22)

So the usability of this is limited - you can only intercept errors that you explicitly raised yourself.

----
[Arts and crafts of Tcl-Tk programming]
}