Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: break/continue vs. try-always



On Thu, 12 Jun 2014 23:57:57 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

> On Jun 12,  8:35pm, Peter Stephenson wrote:
> }
> } This makes a break or continue at the end of a function produce a
> } warning.  It didn't seem worth a hard error, but presumably a break or
> } continue is usually intended to do something so it should be reported if
> } it doesn't.
> 
> Hrm.  That makes it sort of like WARN_CREATE_GLOBAL.  I can think of
> cases where you want the warning, and cases where you don't ... the
> situation that got us to this point is one of latter.

I agree there's no obvious single right answer.  In the test code, we
can handle the warning when it appears, however: it's inside any
redirection of test output.

> } +When this option is not set, the effect of tt(break) and tt(continue)
> } +commands may propagate outside function scope, affecting loops in
> } +calling functions.  When this option is not set, a tt(break) or
> } +a tt(continue) that is not caught within a function produces a warning.
> 
> Typo, extra "not" in the last sentence.

Yes, and I improved the documentation after I'd sent the patch to make it
clearer what happens where.

> } +	opts[LOCALLOOPS] = saveopts[LOCALLOOPS];
> } +    }
> } +
> } +    if (opts[LOCALLOOPS]) {
> } +	if (contflag)
> } +	    zwarn("`continue' active at end of function scope");
> } +	if (breaks)
> } +	    zwarn("`break' active at end of function scope");
> } +	contflag = breaks = 0;
> 
> Since breaks is saved as obreaks on entry to doshfunc, shouldn't this be
> 
> 	breaks = obreaks;
> 
> Also, probably need to save/restore contflag and loops?  In case the
> function is called from a trap handler, for example?

As this is a new feature anyway, there's no reason we shouldn't do
that.  I couldn't think of a case where the continue or break wouldn't
already have been dealt with if they were set; traps do the saving and
restoring of stuff elsewhere.  But for a couple of extra variables it seems
a reasonable piece of safety.

pws



Messages sorted by: Reverse Date, Date, Thread, Author