5
votes

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?

3

3 Answers

11
votes

Can you show how you catch/puts the information in non-interactive mode?

If you did

if {[catch {...your...code...here...} err]} {
   puts "Error info $err"
}

Then the behavior you described is expected - $err only has the "terse info". What you might want to puts instead is:

   puts "Error info $err\nFull info: $::errorInfo"

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 test1 and test2 differ because of where you've placed the catch. Let me illustrate. Here are some chained Tcl procs:

proc one {} {
  two
}
proc two {} {
  three
}
proc three {} {
  four
}
proc four {} {
  error "Yup, an error"
}

If you evaluate

catch {four}
puts $::errorInfo

You will just get a stack trace that looks like this:

Yup, an error
    while executing
"error "Yup, an error""
    (procedure "four" line 2)
    invoked from within
"four"

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:

catch {one}
puts $::errorInfo

The stack trace between the catch statement and the error includes the procs one, two, three, and four. This results in a stack trace like so:

Yup, an error
    while executing
"error "Yup, an error""
    (procedure "four" line 2)
    invoked from within
"four"
    (procedure "three" line 2)
    invoked from within
"three"
    (procedure "two" line 2)
    invoked from within
"two"
    (procedure "one" line 2)
    invoked from within
"one"

So... to match your example for test1, if you redefined three as follows:

proc three {} {
  catch {four}
  puts $::errorInfo
}

And you evaluated

if {[catch {one}]} {
   puts "Found an error"
}

You would not see "Found an error", because the body of three caught the error, and printed the stack trace. The stack trace only containing the calls between the catch statement and the error - which (like my first example) consists only of the call to four.

So, where you place your catch statements 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:

proc three {} {
  if {[catch {four} err]} {
    puts "Caught an error $err, re-throwing"
    error $err $::errorInfo
  }
}

Now, with the re-thrown error, you would see this:

tchsh% catch {one}
Caught an error Yup, an error, re-throwing
1
tclsh% set ::errorInfo
Yup, an error
    while executing
"error "Yup, an error""
    (procedure "four" line 2)
    invoked from within
"four"
    (procedure "three" line 2)
    invoked from within
"three"
    (procedure "two" line 2)
    invoked from within
"two"
    (procedure "one" line 2)
    invoked from within
"one"
1
votes

Given your further refinement of your question, the following may work for you:

# gets the stack up to the caller
proc get_stack {} {
    set result {}
    for {set i [expr {[info level] -1}]} {$i >0} {incr i -1} {
        lappend result [info level $i]
    }
    return $result
}

# formats the stack for display
proc format_stack {stackList} {
    return "\twhile executing: [join $stackList \n\twhile\ executing:\ ]"
}

# test function that has an error
proc test3 {x y} {
    set list {1 2 3 4 5}
    set sum 0
    foreach el $list {
        if {[catch {set sum [expr $sum + $element]} err]} {
            puts "$::errorInfo\n[format_stack [get_stack]]"
        }
        break 
    }
}

# wrapper test function, just so we can show the call stack more visibly
proc test4 {a b c} { 
    test3 A B
}

# and, we call it and show the output
% test4 1 2 3
can't read "element": no such variable
    while executing
"expr $sum + $element"
    while executing: test3 A B
    while executing: test4 1 2 3
0
votes

It depends how close to the error site you catch it. The stack trace in errorInfo is built up as the stack is unwound from the error site back to the first enclosing catch or the top level - see tutorial. So if you have a catch in the proc where the error occurs it doesn't get a chance to build the stack trace in errorInfo.