Re: Revisiting Error handling (errexit)

[Yair Lenga]

Sent from my iPad

> On Jul 6, 2022, at 1:07 AM, Lawrence Velázquez <vq@larryv.me> wrote:
> 
> On Tue, Jul 5, 2022, at 5:18 PM, Yair Lenga wrote:
>> I’m not in front of my desktop, so I can not verify behavior, but here 
>> is my expectation - let me know if it make sense, in the context of the 
>> project goal - every unhandled failed statement should unwind execution 
>> up, until explicitly handled.
> 
> But you've said that this won't apply to the topmost level, so
> you've already introduced a distinction between that level and every
> other level, which will have to be explained.
> 
By top level, I refer to the REPL (read-eval-print) loop. It can  be handled as 
well. My personal opinion is to leave the REPL loop untouched (see below). 
However, if there is agreement that the this is the right implementation, I 
will add it to the next patch set.

Why addressing the REPL is not important: in general, for complex scripts, I 
prefer to move the ‘main’ logic into a function (‘main’, ‘run’,…). This make it 
possible to keep clean name space. Otherwise, all the main variables are 
becoming global: see below for ‘x’. With many variables, it can be ugly.

Function main () { 
    Local x.   # x is local
    For x in a b ; do process $x ; done
}

Vs.
# x is global, all function will see it.
For x in a b ; do process $x ; done

> 
>>> if false ; echo Foo ; [[ notempty ]] ; then echo Full ; else echo Empty ; 
>>> fi || echo Fail
>>> 
>> Output: Empty
>> If false … should fail on the first false, going to the else part, 
>> printing Empty. Since the ‘echo empty’ succeeded, Fail will not be 
>> printed.
>> 
>>> or
>>> 
>>> if { false ; echo Foo ; [[ notempty ]] ; } ; then echo Full ; else echo 
>>> Empty ; fi || echo Fail
>>> 
>> Output: Empty
>> Same as above. Grouping does not change behavior.
>>> or
>>> 
>>> if ( false ; echo Foo ; [[ notempty ]] ) ; then echo Full ; else echo Empty 
>>> ; fi || echo Fail
>>> 
>> Output: empty
>> Same as above. Running in a subshell does not change behavior.
>>> or 
>>> 
>>> for x in a b ; do if false ; echo Foo ; [[ notempty ]] ; then echo Bar ; 
>>> else echo Empty ; fi ; done
>> Output: Empty (for a), Empty (for b)
>> Since the if statement succeed, the code will flow to from the first 
>> iteration to the second iteration. 
> 
> In a nutshell, you are proposing that this:
> 
>    set -o errfail
>    if false; true; then cmd1; else cmd2; fi
> 
> ...should behave like this:
> 
>    if false; then cmd1; else; cmd2; fi
> 
> Okay, but...
> 
> 
>> The last case has interesting variant: the case when the loop body fail 
>> (for x in a b ; do echo $x ; false ; done.
>> Output: a
>> In this case, the code failed body will result in effective ‘break’ to 
>> the loop, where the whole for statement will fail. I believe this case 
>> is not currently covered in the implementation (2 or 3 lines to cover 
>> each of the loop constructs: for (list, arithmetic), until and while.
> 
> ...now you are applying different logic to "for" commands.  You
> want this to stop iterating:
> 
>    set -o errfail
>    for word in a b c; do false; true; done
> 
> ...which is NOT what this does:
> 
>    for word in a b c; do false; done
> 
> Yet another inconsistency that will have to be explained.

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. 
> 
> Contrary to your pitch, this option is shaping up to be about as
> incoherent as errexit.  You should heed the suggestion to iron out
> the semantics.
> 
> 
See my notes. Might be too early to judge the solution, as We are only starting 
to get community feedback. The comments from Martin helped me realized the need 
to apply consistent behavior for the ‘body’ part of the if, until, while, for 
list and arithmetic for. I am looking for additional community feedback that 
will make the proposal and implementation useful, clean and productive to the 
bash community and users.

Regards,
Yair.
> -- 
> vq