CODEWITHSUNDEEP
tcl
maiky
maiky

Reputation: 3653

How can I get the code line number along with errorinfo but prior to 8.5?

I am using the following TCL code:

proc RunCSM { scen } {
                catch { $scen start }
                if { "[$scen status]" != "SUCCESS" } {
                        puts "$scen FAILED.  Error Info:"
                        puts "[$scen errorInfo]" ...

I need also the line number of the code that fails. In 8.5 and onwards this is achieved by this nice solution How can I get the code line number along with errorinfo?

How is it possible to achieve the same but in version 8.4?

Upvotes: 0

Views: 102

Answers (1)

Donal Fellows
Donal Fellows

Reputation: 137567

The easiest approach is to parse the errorInfo variable. Here's what an example looks like:

% parray foo
"foo" isn't an array
% set errorInfo
"foo" isn't an array
    while executing
"error "\"$a\" isn't an array""
    (procedure "parray" line 4)
    invoked from within
"parray foo"

Parsing that with regexp isn't too hard, provided we use the -line option.

proc getLineFromErrorInfo {} {
    global errorInfo
    if {[regexp -line { line (\d+)\)$} $errorInfo -> line]} {
        return $line
    } else {
        # No guarantee that there's information there...
        return "unknown"
    }
}

On our example from before, we can then do:

getLineFromErrorInfo

and it will return 4. You might want to extend the RE to also capture the name of the procedure; line numbers in 8.4 and before are always relative to their procedure. (This is also mostly true in 8.5 onwards; this is an area where backward compatibility is a bit painful IMO.) Here's how you might do that:

proc getLocusFromErrorInfo {} {
    global errorInfo
    if {[regexp -line {\(procedure "(.*?)" line (\d+)\)$} $errorInfo -> proc line]} {
        return [list $proc $line]
    } else {
        # No guarantee that there's information there...
        return "unknown"
    }
}

Note that merely knowing where the error came from doesn't necessarily tell you where the problem is, especially in production code, since it could be due to bad arguments elsewhere that have been passed around a bit…

Upvotes: 2

Related Questions