Tcl Source Code

When an error occurs in a variable trace with
message $msg, the operation on the variable returns
an stack trace like:

can't set "foo": $msg
    while executing
set foo bar

Unless all your error messages are unique, or you
never put multiple traces on a variable (and never
chain traces), that's not enough information to
find the problem.  Debugging variable traces is
thus much harder than it should be.

I would rather the stack trace were like:

$msg
<rest of stack trace, formerly lost>
    (write trace on "foo")
    while executing
set foo bar

This can be done by not calling VarErrMsg when
reporting errors in variable traces.

Any reason not to make this change?

File Added - 107497: tk.patch

Logged In: YES 
user_id=80530

additional patch for Tk test suite.

File Deleted - 107483: 



File Added - 107490: 527164.patch

Logged In: YES 
user_id=80530

final patch includes test suite updates.

committing for Tcl 8.5a2.

Debugging errors in traces should
be much easier now.

File Deleted - 107412: 



File Added - 107483: 527164.patch

Logged In: YES 
user_id=80530

updated patch provides the
::errorInfo preserving
benefits, but keeps much
better compatibility.

Logged In: YES 
user_id=79902

Patch looks likely to succeed and I approve of the general
change. Assigning back to author for test suite updates.

File Deleted - 20232: 



File Added - 107412: 527164.patch

Logged In: YES 
user_id=80530

patch updated to HEAD.
needs review and tests
(new and revised)

Logged In: YES 
user_id=80530

worth another look now.

File Deleted - 20173: 



File Added - 20232: vartrace.patch

Logged In: YES 
user_id=80530

Patch updated to the current HEAD.  Stil does not work.

Logged In: YES 
user_id=80530


OK, the patched Call Traces will now preserve
any stack trace info that's already in ::errorInfo.

The problem is that TraceVarProc calls
Tcl_RestoreResult which in turn calls
Tcl_ResetResult.  This destroys all stack
information in ::errorInfo before control
ever gets back to CallTraces.

Note sure whether this can be fixed.  The calls
to Tcl_SaveResult and Tcl_RestoreResult in
TraceVarProc could be removed, but that might
break the interface of traces.  Tcl_RestoreResult
could be changed to not call Tcl_ResetResult, but
that also might be an incompatible interface change.

Logged In: YES 
user_id=80530

patch does not appear to work.

File Added - 20173: vartrace.patch

Logged In: YES 
user_id=80530


Here's a patch that includes the effects of Patch 535952
and the additional changes to preserve ::errorInfo
from variable traces.

It does not include updates to the test suite, neither
changes to existing tests, nor new tests to test the new
functionality.

Logged In: YES 
user_id=80530

Note that after accepting Patch 535952, this change can
be made by modifications to a single routine, CallTraces.

Logged In: YES 
user_id=79902

Integrating variable trace failures with the other errors
that can happen when reading or writing a variable is a bit
of a pain (TIP #68 cleaned this up a bit, but it still isn't
pretty); at the moment there is no way to indicate whether a
particular message came from a trace or from somewhere else,
which is exactly what you need when trying to work out
whether to reinitialise the errorInfo variable.

Logged In: YES 
user_id=80530


That's also worth considering, but I think it's a
separate issue from the request in this report,
and I'd like to consider it separately.

Logged In: YES 
user_id=148712

I do not see any reason not to, except maybe that some app
might possibly be relying on the precise wording of the
stack trace.

By the way, if we do change errorInfo details: I'd like to
get rid of the distinction between "while executing" and
"invoked from" - I'm having quite a bit of trouble
reproducing that exact structure in an attempt to have
errorInfo be generated lazily. So, either there is no real
logic behind that distinction, or else I'm missing it
completely. Any reason not to unify those messages too?