Tcl Source Code

View Ticket
Login
Ticket UUID: 2689307
Title: errorCode no longer set correctly in interactive mode
Type: Bug Version: obsolete: 8.6b1.1
Submitter: tallniel Created on: 2009-03-16 22:51:46
Subsystem: 07. Variables Assigned To: dgp
Priority: 9 Immediate Severity:
Status: Closed Last Modified: 2009-03-18 23:52:25
Resolution: Fixed Closed By: dgp
    Closed on: 2009-03-18 16:52:25
Description:
Current CVS HEAD Tcl no longer seems to set the errorCode global variable correctly when operating in interactive mode:

% info patch
8.6b1.1
% expr {1/0}
divide by zero
% set errorCode
TCL LOOKUP VARNAME

The correct errorCode (ARITH DIVZERO...) is produced when using [catch] or when placing the above code in a script. This seems to
happen for all errors, including those created with throw/error or thrown from within procedures.
User Comments: dgp added on 2009-03-18 23:52:25:

allow_comments - 1


committed.

dgp added on 2009-03-18 23:42:10:

File Added - 318396: 2689307.patch


Attached patch takes the errorCode
setting out of TclLookupSimpleVar()
and pushes the burden up onto its
callers.
File Added: 2689307.patch

dgp added on 2009-03-18 20:16:29:
ok, can't reach final solution on this
attempt, but it's looking like the issue
to chase down is whether all the machinery
in tclVar.c is resepecting the TCL_LEAVE_ERR_MSG
flag when present and when absent.

dgp added on 2009-03-18 20:11:56:
errorCode is overwritten during the
Tcl_GetVar2Ex() call at line 776 of
tclMain.c.

The TCL_LEAVE_ERR_MSG flag is not set.

dgp added on 2009-03-18 20:06:45:
still mysterious is why
errorCode gets an overwrite, but
errorInfo is unmolested.

dgp added on 2009-03-18 20:04:47:
Appears to be droppings from (in effect) the
[catch $::tcl_prompt1] use to support
interactive prompt customization.

dgp added on 2009-03-18 03:38:17:
dkf's 2009-01-08 commit appears to be
the trigger.

tallniel added on 2009-03-17 20:41:58:
Seems to be a regression since then. 8.6b1 produces the correct ARITH DIVZERO errorCode.

dgp added on 2009-03-17 20:25:20:
Is this also true for the 8.6b1 release,
or is this a regression since then?

Attachments: