bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Revisiting Error handling (errexit)


From: Lawrence Velázquez
Subject: Re: Revisiting Error handling (errexit)
Date: Tue, 05 Jul 2022 18:06:40 -0400
User-agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7

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.


>> 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.

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.


-- 
vq



reply via email to

[Prev in Thread] Current Thread [Next in Thread]