[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 { … }
>
Re: Revisiting Error handling (errexit), Yair Lenga, 2022/07/05
- Re: Revisiting Error handling (errexit), Lawrence Velázquez, 2022/07/05
- Re: Revisiting Error handling (errexit), Yair Lenga, 2022/07/05
- Re: Revisiting Error handling (errexit), Lawrence Velázquez, 2022/07/05
- Re: Revisiting Error handling (errexit), Yair Lenga, 2022/07/05
- Re: Revisiting Error handling (errexit), Lawrence Velázquez, 2022/07/05
- Re: Revisiting Error handling (errexit), Martin D Kealey, 2022/07/06
- Re: Revisiting Error handling (errexit),
Yair Lenga <=
- Re: Revisiting Error handling (errexit), Koichi Murase, 2022/07/06
- Re: Revisiting Error handling (errexit), Yair Lenga, 2022/07/06
Re: Revisiting Error handling (errexit), Koichi Murase, 2022/07/06
Re: Revisiting Error handling (errexit), Martin D Kealey, 2022/07/05
Re: Revisiting Error handling (errexit), Robert Elz, 2022/07/06