Re: break/continue vs. try-always

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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 {
          fn_somebody_else_wrote_that_calls_break_1000
       } always {
          print dammit there should be some way not to break here
       }
    done
  }

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
return?

} 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?