Re: catch replacing useful errorInfo

On Aug 30, 7:35 am, Donald G Porter <d...@xxxxxxxx> wrote:
tom.rmadilo wrote:
error $err $::errorInfo $::errorCode
Yes you are right, if you do a catch, you should somehow log the
current value of errorInfo. You really need to also log where the
catch takes place, because the location of the catch is not part of
the errorInfo. Catch destroys this information, in this specific
sense.

Either you're just plain wrong, or I don't understand what you're
saying. Let's look at the corrected example again:

% proc err {} {incr foo oops! ;# error here}
% proc errCaller {} err
% proc demo {} {
if {[catch errCaller msg] == 1} {
error $msg $::errorInfo $::errorCode
}}

% demo
expected integer but got "oops!"
% set errorInfo
expected integer but got "oops!"
(reading increment)
invoked from within
"incr foo oops! "
(procedure "err" line 1)
invoked from within
"err"
(procedure "errCaller" line 1)
invoked from within
"errCaller"
(procedure "demo" line 2)
invoked from within
"demo"

Now, in the context of this example, can you please point to
what information was "destroyed". It appears to me that
all procs on the call stack at the time of the original error
appear in the $::errorInfo, providing complete data on the
context of the error.

Maybe more later if we get this misunderstanding cleared up.


I can't see how this differs from what I said: errorInfo does not
contain the location of the catch, but you didn't look at the value of
errorInfo after the catch, only after demo. Your code does exactly
what I suggested you should do, which is to propagate the error, or
log errorInfo plus the location.

If you run the modified demo:

proc demo {} {
if {[catch errCaller msg] == 1} {
global errorInfo
puts $errorInfo
error $msg $::errorInfo $::errorCode
}
}

% demo
expected integer but got "oops!"
(reading increment)
invoked from within
"incr foo oops! "
(procedure "err" line 1)
invoked from within
"err"
(procedure "errCaller" line 1)
invoked from within
"errCaller"

And as you can see, errorInfo did not contain the caller, but after
your new call to error, it does:

% set errorInfo
expected integer but got "oops!"
(reading increment)
invoked from within
"incr foo oops! "
(procedure "err" line 1)
invoked from within
"err"
(procedure "errCaller" line 1)
invoked from within
"errCaller"
(procedure "demo" line 2)
invoked from within
"demo"


Maybe it is easier to say it this way: if you catch an error, throw an
error. Maybe not 100% applicable, but all the examples on this thread
do exactly that. If you don't want to throw an error, figure out how
to avoid the need to catch one.



.