Tcl Source Code

It appears that in 8.4.14 (I don't know about earlier versions...) "return -code error -errorcode xxx" doesn't work. The proper behavior (IMO) is seen in 8.5a4 FWIW. It is the "-errorcode xxx" part that doesn't seem to work.

I expect to get the same results whether I use "return -code error" or "error" but I get different results on 8.4.14 with the following code (on Windows XP):

proc main {} {
    foo return
    foo error
}

proc foo {what} {
    set ::errorCode NULL
    set ::errorInfo ""
    if {[catch {
        if {$what == "error"} {
            error \
                "error reported via error" \
                "custom errorInfo" \
                [list CUSTOM errorCode]

        } else {
            return \
                -code error \
                -errorinfo "custom errorInfo" \
                -errorcode [list CUSTOM  errorCode] \
                "error reported via return"
        }
    } err]} {
        puts $err:
        puts "  errorCode: $::errorCode"
        puts "  errorInfo: $::errorInfo"
        puts ""
    }
}
main
exit 0

Here is what I get with 8.4.14:

error reported via error:
  errorCode: CUSTOM errorCode
  errorInfo: custom errorInfo

error reported via return:
  errorCode: NULL
  errorInfo: 

This is what I get with 8.5a4:

error reported via error:
  errorCode: CUSTOM errorCode
  errorInfo: custom errorInfo

error reported via return:
  errorCode: CUSTOM errorCode
  errorInfo: custom errorInfo

Logged In: YES 
user_id=80530
Originator: NO


I like to think that in Tcl 8.5, the variables
::errorInfo and ::errorCode themselves have
become legacy features.  And for legacy features
we might as well keep as full legacy compat as
we reasonably can.

Since [catch] is extended to capture a
dictionary of return options, there's
no need to read post-catch info from
::errorInfo or ::errorCode; the same info
is better retrieved from the return
options dictionary.

Similarly, since [interp bgerror] permits
registration of a background error handler
that gets passed the full return options
dictionary, there's no need for such a
handler to access such global variables any
longer either.

So, in my mind, the "right" way for scripts
written for Tcl 8.5 to use the ::errorInfo
and ::errorCode variables is not to use them.

This means, that for me the best support
for scripts that do use those variables is
to maintain script-apparent consistency with
how they worked in 8.4.  Some patchwork,
like this one, I don't really like much,
and probably would not have done, except
someone actually did notice the difference.

I figure if someone noticed enough to log
a report, someone else probably has scripts
that depend on the difference 
and will suffer if we don't restore compat.

Other similar examples are 1397843 and 1693252.

I'd be happier if scripts did not exist
that relied on such subtleties of the
former implementation of maintenance
of the ::errorCode and ::errorInfo
variables, but exist they do, and
keeping compat with their needs is easily
enough done.

Logged In: YES 
user_id=68433
Originator: NO

As I understand the initial report, 8.5a4 was doing the _expected_ thing, and 8.4.14's behaviour could be considered a bug.  (FWIW, I agree - although the precise timing of when ::errorCode and ::errorInfo get set doesn't appear to be specified in the manpages, so either way would be reasonable,  8.5's behaviour (without the patch) seems more intuitive to me.)

Is this a matter of bugwards-compatibility?

Logged In: YES 
user_id=80530
Originator: NO

committed that patch plus a test
and ChangeLog entry.

File Added - 231848: 1649062.patch

Logged In: YES 
user_id=80530
Originator: NO


patch updated to HEAD
File Added: 1649062.patch

File Added - 214051: legacy.patch

Logged In: YES 
user_id=80530
Originator: NO


The attached patch for
the Tcl HEAD corrects
the incompatiblity in
maintenance of the legacy
variables ::errorCode and
::errorInfo that is
demonstrated in the report.

I don't really like the
patch much, since it adds
a flag bit to iPtr->flags.
In 8.5 I've been trying to
remove such things, not add
them.

But, if this incompat is
important, I suppose a flag
to get this legacy support
right isn't too bad.

File Added: legacy.patch