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 (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 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.