Re: Revisiting Error handling (errexit)

[Yair Lenga]

My opinion is that we should be looking at the expected behavior - for a 
developer that want to implement ”strong”  error handling: any error will break 
execution until explicitly handled. In the same spirit as the ‘try … catch’ 
that from JavaScript, python, groovy, etc.

So: assuming f1 does not exists,
For f in f1 f2 f3 ; do cat $f ; done || echo “bad cat”

One would expect the “exception” from “cat f1” to ”break” the loop.

Same way that one would expect the “exception” in the function to “return” from 
the function:
Function f { cat f1 ; cat f2 ; cat f3 ; }
F || echo “bad cat”

And for a block, one would expect the block to be ’unwind’ (no existing command 
in bash for early exit from a block).
{ cat f1 ; cat f2 ; cat f3 ; } || echo “bad cat”

To push the limit, using function f from above, will result in the “exception” 
triggering both return and break.
For x in a b ; do f ; done || echo “bad cat”

I think that all four cases, while each one matches different existing bash 
command(s) (break, return, and ‘unwind’, and return+break) are consistent with 
the accepted / expected pattern for try … catch, and most developers will 
understand how to use it.

Hope it make sense. In any case, I would like to ask for some time until 
additional community input/comments are sorted out. While the final result may 
be different from where we started, I hope it will be better.

Side comment: I think the following should work: 😺
Alias try=‘if !’
Alias catch=‘then’

Try { cat f1 ; cat f2 ; cat f3 ; }       # 🐈🐈🐈
Catch { echo “bad cat” ; }.           # 🐈‍⬛🐈‍⬛🐈‍⬛

Yair.

Sent from my iPad

> On Jul 6, 2022, at 2:19 AM, Lawrence Velázquez <vq@larryv.me> wrote:
> 
> On Tue, Jul 5, 2022, at 6:34 PM, Yair Lenga wrote:
>> I probably did not described the intended behavior clearly. I believe 
>> both cases should behave identical under errfail. The loop will ‘break’ 
>> on the first iteration (false when word = a). Same for the all looping 
>> commands. I believe this is consistent with if-then-else-if, when an 
>> error in the then or else block will result in terminating (‘breaking’) 
>> the if. 
> 
> It's only consistent if your notion of consistency is "terminate
> all compound commands immediately".  This kind of works for "if"
> but changes "for" and "while" in a very fundamental way.  Your
> initial description of "treat a; b; c like a && b && c" implies
> that
> 
>    if condition; then a; b; c; fi
> 
> should behave like
> 
>    if condition; then a && b && c; fi
> 
> and
> 
>    for word in words; do a; b; c; done
> 
> should behave like
> 
>    for word in words; do a && b && c; done
> 
> but it turns out what you apparently want is
> 
>    for word in words; do a && b && c || ! break; done
> 
> which is a larger change than you let on.
> 
> -- 
> vq