If using Tcl in interactive mode , in which I input the following:
set list {1 2 3 4 5}
set sum 0
foreach el $list {
set sum [expr $sum + $element]
}
it will show a piece of very terse info:
can't read "element": no such variable
but when I use
puts $errorInfo
it wil show:
can't read "element": no such variable
while executing
"expr $sum + $element"
("foreach" body line 2)
invoked from within
"foreach el $list {
set sum [expr $sum + $element]
}"
which is what I really want.
The problem is : in non-interactive mode when I want to catch this error and then puts the errorInfo to get a stack trace, it’ll merely display the terse info. How can I get the detailed stack trace like above? Thanks a lot!
Edited to add more details
say I have following code:
proc test1 {} {
set list {1 2 3 4 5}
set sum 0
foreach el $list {
if {[catch {set sum [expr $sum + $element]} err]} {
puts $::errorInfo
}
break
}
}
proc test2 {} {
foreach el $list {
set list {1 2 3 4 5}
set sum 0
set sum [expr $sum + $element]
}
}
#test1
#test2
If I uncomment "#test1", it’ll show :
can't read "element": no such variable
while executing
"expr $sum + $element"
if I uncomment "#test2", it’ll show:
can't read "element": no such variable
while executing
"expr $sum + $element"
(procedure "test2" line 5)
invoked from within
"test2"
(file "./test.tcl" line 137)
What I want is of course the test2 behavior. How can I display this error info using catch?
Can you show how you catch/puts the information in non-interactive mode?
If you did
Then the behavior you described is expected –
$erronly has the “terse info”. What you might want toputsinstead is:The prefix
::is required in case your catch is called inside a proc or namespace to ensure that the variable you use is the actual toplevel ::errorInfo.Edited to address the followup
As Colin answered, the stack traces found in your
test1andtest2differ because of where you’ve placed the catch. Let me illustrate. Here are some chained Tcl procs:If you evaluate
You will just get a stack trace that looks like this:
This is because the stack trace between where the error happened (inside
four) and where you caught it, there is only one procedure call.If instead you caught the error “further away” like so:
The stack trace between the
catchstatement and the error includes the procsone,two,three, andfour. This results in a stack trace like so:So… to match your example for
test1, if you redefinedthreeas follows:And you evaluated
You would not see “Found an error”, because the body of
threecaught the error, and printed the stack trace. The stack trace only containing the calls between thecatchstatement and the error – which (like my first example) consists only of the call tofour.So, where you place your
catchstatements matter.On a related note, you can re-throw the error, preserving the stack trace if you so desire. Here’s the new definition for
three:Now, with the re-thrown error, you would see this: