Re: Inconsistent behavior of ERR_EXIT with conditionals

[Lawrence Velázquez <larryv@xxxxxxx>]

On Thu, Nov 10, 2022, at 10:04 PM, Philippe Altherr wrote:
> However, in my 
> experience, ERR_EXIT is often used as a safeguard for standalone 
> scripts. Even though it's far from perfect, it's definitely better than 
> nothing.

Debatable.


> Every now and then one of 
> these exceptions that you thought could/should never be thrown is 
> nevertheless thrown for some reason. In that case the exception goes up 
> the call stack and, if no catch is encountered, it kills the program 
> and prints a stack trace to the code that threw the exception. This way 
> it's obvious that something failed. It's also easy to figure out where 
> it happened. And, it ensures that no extra harm is done (by keeping 
> running the program).

Only at a superficial level.

https://devblogs.microsoft.com/oldnewthing/20040422-00/?p=39683


> In the world of shell scripts, there are no runtime exceptions but some 
> exit statuses play a similar role. Many UNIX commands and shell 
> functions can potentially return a non-zero exit status but when you 
> use them you often know (or assume) that they won't return a non-zero 
> exit status.

Some nonzero exit statuses signify errors that should be fatal.
Some don't.  Some don't really indicate errors at all.  ERR_EXIT
makes no distinction, which is why it can cause confusion when it
kills scripts overzealously.

https://mywiki.wooledge.org/BashFAQ/105


> If they nevertheless do, the default behavior of shell 
> script is to simply ignore the error. So if "cmd1" fails in "cmd1; 
> cmd2", "cmd2" still gets executed. It's already bad that "cmd1" failed. 
> Running "cmd2" could cause extra harm. It looks much safer to exit 
> right after "cmd1". That's the main reason I run all my scripts with 
> ERR_EXIT enabled.

You should handle errors properly instead of relying on ERR_EXIT
to bail you out.


> My impression is that ERR_EXIT is commonly used for these reasons.

It is.  That doesn't mean it's a good idea.


> In my opinion, the only downside of that usage of ERR_EXIT is that it's 
> far from foolproof.

Lulling script writers into a false sense of security is a pretty
big downside.


> There are plenty of cases where just enabling 
> ERR_EXIT won't be enough to ensure that the script halts at the first 
> unexpected error. I would like to improve that. My zabort script 
> already goes a long way.

I do not think this idea is an improvement.  I think it is more of
the same false sense of security, except with rules that are somehow
even more convoluted than those of ERR_EXIT.


> It works around the non-propagation issues, 
> which are by far the main reason why just ERR_EXIT isn't enough.

ERR_EXIT isn't enough because it shoehorns an error handling model
into a context where it doesn't really fit.  Unfortunately that
ship has already sailed, but it's sailed on all shells, so at least
we have company.  I do not think zsh should exacerbate the situation
by shoehorning even harder, and I oppose the addition of an option
for doing so.


-- 
vq