if 0 {Richard Suchenwirth 2003-07-29 - Errors 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 $code}
if {$line=="c"} break
catch {uplevel 1 $line} res
puts $line
}
}if 0 {The test code is heavily putsy 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.