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 ([a minimal debugger]), where you can check what went wrong, maybe fix it, and decide to "c"ontinue (i.e. resume after the place the error was raised) or keep the error for the real handler ("x"):
}
 proc error {code args} {
    puts $code/$args
    while 1 {
        puts -nonewline "% "
	flush stdout
	gets stdin line
	if {$line=="x"} {tcl::error $code}
	if {$line=="c"} break
	catch {uplevel 1 $line} res
	puts $res
    }
 }
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]
}