Re: Revisiting Error handling (errexit)

[Saint Michael]

Sounds great to me. I also use Bash for mission-critical processes.
Philip

On Mon, Jul 4, 2022 at 8:22 AM Yair Lenga <yair.lenga@gmail.com> wrote:
>
> Hi,
>
> In my projects, I'm using bash to manage large scale jobs. Works very well,
> especially, when access to servers is limited to ssh. One annoying issue is
> the error handling - the limits/shortcomings of the 'errexit', which has
> been documented and discussed to the Nth degree in multiple forums.
>
> Needless to say, trying to extend bash to support try/catch clauses, (like
> other scripting solutions: Python, Groovy, Perl, ...), will be a major
> effort, which may never happen. Instead, I've tried to look into a minimal
> solution that will address the most common pitfall of errexit, where many
> sequences (e.g., series of commands in a function) will not properly
> "break" with 'errexit'. For example:
>
> function foo {
>     cat /missing/file   # e.g.: cat non-existing file.
>     action2   # Executed even if action 1 fail.
>     action3
> }
>
> set -oerrexit   # want to catch errors in 'foo'
> if ! foo ; then
>     # Error handling for foo failure
> fi
>
> I was able to change Bash source and build a version that supports the new
> option 'errfail' (following the 'pipefail' naming), which will do the
> "right" thing in many cases - including the above - 'foo' will return 1,
> and will NOT proceed to action2. The implementation changes the processing
> of command-list ( '{ action1 ; action2 ; ... }') to break of the list, if
> any command returns a non-zero code, that is
>
> set -oerrfail
> { echo BEFORE ; false ; echo AFTER ; }
>
> Will print 'BEFORE', and return 1 (false), when executed under 'errfail'
>
> I'm looking for feedback on this implementation. Will be happy to share the
> code, if there is a chance that this will be accepted into the bash core
> code - I believe it will make it easier to strengthen many production
> systems that use Bash.
>
> To emphasize, this is a minimal proposal, with no intention of expanding it
> into full support for exceptions handling, finally blocks, or any of the
> other features implemented in other (scripting) languages.
>
> Looking for any feedback.
>
> Yair