From: "Lawrence Velázquez" <larryv@zsh.org>
To: "Philippe Altherr" <philippe.altherr@gmail.com>,
"Bart Schaefer" <schaefer@brasslantern.com>
Cc: zsh-workers@zsh.org
Subject: Re: Inconsistent behavior of ERR_EXIT with conditionals
Date: Thu, 10 Nov 2022 23:06:39 -0500 [thread overview]
Message-ID: <6ddc4f89-e717-485b-aeae-e9b8fbbce2da@app.fastmail.com> (raw)
In-Reply-To: <CAGdYchteCWPt_2skasZr3suB6HKxtnT4-ARAjivT1BkeGDdy6A@mail.gmail.com>
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
next prev parent reply other threads:[~2022-11-11 4:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 16:37 Philippe Altherr
2022-11-06 20:45 ` Bart Schaefer
2022-11-07 3:50 ` Bart Schaefer
2022-11-07 5:35 ` [PATCH] " Bart Schaefer
2022-11-07 9:44 ` Peter Stephenson
2022-11-08 1:20 ` Bart Schaefer
2022-11-08 4:58 ` Philippe Altherr
2022-11-08 5:36 ` Bart Schaefer
2022-11-08 8:04 ` Lawrence Velázquez
2022-11-08 18:51 ` Philippe Altherr
2022-11-08 19:20 ` Lawrence Velázquez
2022-11-08 23:28 ` Bart Schaefer
2022-11-09 4:11 ` Philippe Altherr
2022-11-09 6:00 ` Bart Schaefer
2022-11-09 14:22 ` Philippe Altherr
2022-11-10 1:00 ` Bart Schaefer
2022-11-10 5:09 ` Bart Schaefer
2022-11-11 3:04 ` Philippe Altherr
2022-11-11 4:06 ` Lawrence Velázquez [this message]
2022-11-11 4:09 ` Eric Cook
2022-11-08 23:11 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6ddc4f89-e717-485b-aeae-e9b8fbbce2da@app.fastmail.com \
--to=larryv@zsh.org \
--cc=philippe.altherr@gmail.com \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).