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

Re: break/continue vs. try-always

On Jun 8,  6:54pm, Peter Stephenson wrote:
> On Fri, 06 Jun 2014 23:22:50 -0700
> Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > I don't understand what "return -r" would do.
> This would allow a sandbox inside a function; otherwise you couldn't
> prevent the user skipping out early, and if you can't put a sandbox
> inside a function the whole concept is degraded in a fairly major way.

Sorry, I'm still not getting it.  The point of being able to reset a
break/continue is because you might have

 fn_that_I_wrote() {
    while some_test_of_mine;
    do {
       } always {
          print dammit there should be some way not to break here

In the case of "return", there is no such situation, again unless you
are considering "trap return EXIT" in which case

    fn_that_I_wrote() {
       (){ douchebag_fn_that_calls_return_in_EXIT_trap } "$@"

is already sufficient.  Which you can also use for a sandbox, no?  Under
what circumstances would I need to use try-always to cancel my own evil

} So we need a syntax plan B.  Variables are possible --- we already do
} stuff with TRY_BLOCK_ERROR, and the code I have working is likewise
} specific to "always" blocks.

Yes, when I first encounterd this I was expecting TRY_BLOCK_ERROR to be
the solution, until I realized that continue was not an error.

} Hmm... along the lines of TRY_BLOCK_ERROR, and as negative numbers
} aren't useful... how about... TRY_BLOCK_RETURN is by default negative,
} but gets set to >= 0 if user signals a return; "always" block can set
} it to some other value, one option would be to negative to prevent the
} return...? This also means you can force a return from the end of the
} always block.

It would generally be useful to know how/why one arrived in the always
block, along the lines of emulating throw/catch ... but again you can
already force a return from the end of the always block with "return"
itself, so I'm not sure a return-specific variable is the right thing.

} > In fact if there are both a "break" and a "continue" in the try-always,
} > the effect is as if "continue" were called with the larger loop count,
} > no matter which of them appears in the try vs. the always blocks.
} Yes, indeed.  The minutiae of the standard may or may not be of some
} help.

It might, but I sort of doubt it, as try-always is not standard; there
is no standard way to switch from breaking to continuing.

I suppose whichever of them is going to affect the larger number of
loops should win.  E.g. if you do "continue 4" while 6 levels deep
and then two levels up (so effectively at "continue 2") the always
block asserts "break 3" then break wins.  Ties ... go to whichever
was called most recently?

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