Must admit your solution shows interesting ideas.
Unfortunately I don"t understand the coding in the regexp function. However, there are some problems with the result. The result shows that the problem is in proc2 with the expr function. But the expr function is in proc3, the called procedure.
Running this program, Tcl reports the error while running proc3 and reports that it is while invoking it from proc2, just what I am looking for. But, if the only way trap this error is with the catch function than it's too complicated because I can't include a catch function for each line of code. The bgerror doesn't catch it, I tried.
Relying on the Tcl error handler, unfortunately is problematic. I've seen a lot of error reports that don't fit on the page. This is where the problem is, it tries to show too much and I can't see the calling procedure reported.
I have a simple but awkward solution for this. Add an extra argument to each procedure. Let this argument be the name of the procedure itself. Then, for debugging, while the called procedure is running the calling procedure may be obtained just by looking at the argument;
proc prog1 {prog} {
set arg1 25
set val1 [prog3 $arg1 prog1]
return $val1
}
proc prog2 {prog} {
set arg2 ab
set val2 [prog3 $arg2 prog2]
return $val2
}
proc prog3 {ghj prog} {
set val3 [expr $ghj + 3]
return $val3
}
set val4 [prog2 inline]
Running this now, would issue an error in prog3 showing the expr to be at fault with the 'ab' element. Now where does this come from? placing a trap prior to expr function and display the variable prog. This would show prog2, the calling program, and where the problem lies:
proc prog3 {ghj prog} {
message_box $prog
set val3 [expr $ghj + 3]
return $val3
}