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
}
proc error {code args} { puts $code/$args while 1 { puts -nonewline "% " flush stdout gets stdin line if {$line=="x"} {tcl::error $code} if {$line=="p"} { set self [info level -1] puts "$self {[info body [lindex $self 0]]}" continue } 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.