107
Error handling in bash
(notifox.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 11 Feb 2026
107 points (99.1% liked)
Programming
25502 readers
343 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
In my experience this option is too risky. Making simple changes to the script without scientifically proofing and testing it works under all cases becomes impossible (depending on how complex the script and task itself is). It has a bit of the energy of "well you have to make no errors in C, then you can write good code and it never fails".
This option is good if the script MUST fail under any circumstances, if any error return of a program occurs. Which is usually not the case for most scripts. It's also useful in testing when debugging or when developing. Also useful if you purposefully enable and disable the option on the fly for sensitive segments of the script. I do not like this option as a default.
I don't have the Bash experience to argue against that, but from a general programming experience, I want things to crash as loudly as possible when anything unexpected happens. Otherwise, you might never spot it failing.
Well, and nevermind that it could genuinely break things, if an intermediate step fails, but it continues running.
Bash and the commandline are designed to work after an error. I don't want it to fail after an error. It depends on the error though, and how critical it is. And this option makes no distinction. There are lot of commands where a fail is part of normal execution. As I said before, this option can be helpful when developing, but I do not want it in production. Often "silent" fails are a good thing (but as said, it depends on the type). The entire language is designed to sometimes fail and keep working as intended.
You really can't compare Bash to a normal programming language, because the language is contained and developed in itself. While Bash relies on random and unrelated applications. That's why I do not like comparisons like that.
Edit: I do do not want to exit the script on random error codes, but maybe handle the error. With that option in place, I have to make sure an error never happens. Which is not what I want.
But you can just as well make an exception to allow errors when -e is enabled with something like
command || true, or even some warning message.I feel like, while it does occur, allowing errors like this is more unusual than stopping the script in an error, so it's good to explicitly mark this case, therefore -e is still a reasonable default in most cases.