bug-bash
[Top][All Lists]
Advanced

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

Re: Revisiting Error handling (errexit)


From: Yair Lenga
Subject: Re: Revisiting Error handling (errexit)
Date: Wed, 6 Jul 2022 12:15:28 +0300

Hi. Thanks for proposal.

For my use case, where I have large existing code base, where I want to
improve error checking, and avoid unhandled errors, per function setting
will not work. This will also deviate from the try ... Catch pattern used
in many other scripting solution, making it hard for developer to adapt.
Asking for large set of changes (touch each function) not realistic for
many production environments.

That said, there might be some other use cases for limited scope. Probably
make sense to restore that errfail when a function exit. Practically
allowing more scoped execution.

Function foo {  Set -oerrfail: ... ; }

Function bar { foo ; zap ; } ;

Function foo will run with errfail logic. But bash will revert back to no
errfail when control revert back to bar, and zap will run WITHOUT errfail.
I remember reading about other bash setting that are automatically restored
on function exits. Can not remember which one.

Another  interesting option will be to limit the errfail to "blocks",
allowing something like
{ Set -o errfail ; foo ; bar ; } ; Baz ;

Instead off:
set -o errfail
{ Foo ; bar ; } || true
Set +o errfail.

Reflecting on my own usage, any will work, since I am planning to apply it
globally. Looking for community feedback. Want also to mention that I need
to change on scope of changes for each option - goal is to keep changes to
minimum, avoid risk of  impact on existing scripts.

As of implementing -E, that seems like a big deviation from existing bash
style, and is likely to cause issues for developers targeting solutions
that will be somehow portable between *sh implementation.

Yair.


On Wed, Jul 6, 2022, 11:24 AM Martin D Kealey <martin@kurahaupo.gen.nz>
wrote:

> Modules can have conflicting requirements of global settings that require
> weird contortions to interoperate; so starting out by making this yet
> another global setting seems like a retrograde step.
>
> So I would like to propose an alternative approach.
>
> Firstly, I would reduce the action to simply "return from function upon
> unchecked failure"; the issue is primarily with *invisible* behaviour at
> a difference making this difficult to debug.
>
> Secondly I would set this as a per-function attribute, rather than as a
> global setting outside the function.
>
> Perhaps
>
> function -E funcname { … }
>


reply via email to

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