[Tcl-bugs] [ tcl-Bugs-219191 ] return in after script causes bogus bgerror

[SourceForge.net <no...@so...>]

Bugs item #219191, was opened at 2000-10-26 01:03
Message generated for change (Comment added) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=219191&group_id=10894

Category: 03. Timer Events
Group: : 8.0.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Don Porter (dgp)
Summary: return in after script causes bogus bgerror

Initial Comment:
OriginalBugID: 2577 Bug
Version: 8.0.5
SubmitDate: '1999-08-18'
LastModified: '2000-04-03'
Severity: SER
Status: Assigned
Submitter: techsupp
ChangedBy: hobbs
RelatedBugIDs: 3998 750
OS: Solaris
OSVersion: 2.5.1
Machine: Other
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'


Name: Tedd Hadley

Comments:
The reason for the error seems to be code in tclTimer.c AfterProc:
    
        result =  afterPtr->command);
        if (result != TCL_OK) {
            Tcl_AddErrorInfo(interp, "\n    (\after\ script)");
            Tcl_BackgroundError(interp);
        }
    
    Tcl_GlobalEval can, of course, return a value other than TCL_OK without
    it being TCL_ERROR -- TCL_RETURN in this case.  I patched my version
    by changing the condition to if(result == TCL_ERROR).  This may or may
    not be the right fix...

ReproducibleScript:
after 0 {
       return
    }
    update

ObservedBehavior:
return in an after script causes a fake error.

DesiredBehavior:
No error expected



wish4.2 didn't complain, but 8.0+ does. 
-- 04/03/2000 hobbs

----------------------------------------------------------------------

>Comment By: Don Porter (dgp)
Date: 2003-04-28 11:36

Message:
Logged In: YES 
user_id=80530

TIP 90 does not change these things.

This is an effect of TCL_RETURN being
handled by TclUpdateReturnInfo if it
is seen at the toplevel only.  Wish event
loop operates at toplevel; event loops
in commands like [update] or [vwait] 
do not.



----------------------------------------------------------------------

Comment By: Kevin B KENNY (kennykb)
Date: 2002-03-18 16:56

Message:
Logged In: YES 
user_id=99768

Don Porter says that he plans to look at this stuff in the context of
TIP #90: it hits some of the same areas in the code.

----------------------------------------------------------------------

Comment By: Kevin B KENNY (kennykb)
Date: 2001-11-27 19:05

Message:
Logged In: YES 
user_id=99768

We have deeper inconsistencies.

Consider:

% break
invoked "break" outside of a loop
% return -code break
invoked "break" outside of a loop
% continue
invoked "continue" outside of a loop
% return -code continue
invoked "continue" outside of a loop
% return
% return -code return
command returned bad code: 2

Any of the above six commands result in a bgerror with a null message when invoked from [after].

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2001-09-13 16:28

Message:
Logged In: YES 
user_id=80530

OK, now I'm having second thoughts about this
specific bug report.  The "Reproducible Script"
submitted above throws an error in Tcl 7.5 and 7.6
as well as in 8.x.  

As Jeff reports above, things are different in Tk 4.2.
I think it's an improvement that Tk 8 is consistent with
Tcl 8, and the incompatible change did occur at a major
version increment for Tk.

I think there's still a bug here in the form of the
empty error message.  That should be corrected.

Beyond that, if there's still a constituency out there
for accepting TCL_RETURN as the result of evaluation
of an [after] script, they ought to file a feature request.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2001-09-13 14:57

Message:
Logged In: YES 
user_id=80530

I was wrong.  TIP 56 had no effect.  The original
report identified the cause.

Either we should allow TCL_RETURN to be the return code
from an after script, or when we see it, we should
generate an error message stating that it is not allowed.
As is, the empty error message due to no TCL_ERROR does
not help.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2001-09-10 00:48

Message:
Logged In: YES 
user_id=80530

Note that TIP 56 is likely to fix this.

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2000-11-24 08:24

Message:
And if the [return] *is* the current top-level command?  In that case, I read the description as being functionally equivalent to something that just has a result of the given string (like [format %s $string] for example.)

IMHO, what [return] does is make the current context terminate with the given message/code/errorInfo/errorCode.  But what this means at the top-level is a little unclear to me.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2000-11-13 16:53

Message:
I disagree that [return] should throw an error at
level #0.  That's not what the docs say.  From return(n):
...
DESCRIPTION
     Return immediately from the current procedure (or  top-level
     command or source command), with string as the return value.
...

[return] has behaved this way at least as long as I've
used Tcl (since Tcl 7.4), and I've seen plenty of code
that depends on this behavior.  Notably the use of
[return] to exit a pkgIndex.tcl file before the end
of file is quite useful.


----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2000-11-13 08:50

Message:
Return at the global level (which is where after scripts are executed) should always cause an error.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=219191&group_id=10894