Re: Inconsistent behavior of ERR_EXIT with conditionals

[Eric Cook <llua@gmx.com>]

On 11/10/22 22:04, Philippe Altherr wrote:

> I'm mainly a Java developer. In Java many functions may throw runtime exceptions. You can catch and handle these but in 99% of the cases you just ignore them because you know (or assume) that they won't be thrown. Doing otherwise would be very impractical 
> because your code would be littered with try/catch statements. 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).
> 
> 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. 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.
> 
> In addition to that, ERR_EXIT also makes it easier to notice errors and to figure out where they happened, especially if ERR_EXIT is coupled with code that prints a stack trace. Without ERR_EXIT you may not even notice that something went wrong if no 
> error message was printed (or it got swallowed).
> 
> My impression is that ERR_EXIT is commonly used for these reasons. In fact, whenever I have seen it used, it seemed to be for these reasons. But maybe I should confirm that. I'll ask some of my friends if they use it and with what expectations.

Didn't read the entire thread but the first quoted paragraph seems to be the commonly misguided reason to blindly use set -e; attempting to use a paradigm of a language more familiar to the author, to a different language.
As more and more people start their programming careers in languages with exceptions, exception-less languages like unix shells[1] or more recently go-lang[2] looks pretty antiquated.


> In my opinion, the only downside of that usage of ERR_EXIT is that it's far from foolproof. 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.
Correct, it is far from foolproof and it can create additional problems when it unexpectedly unexpected errors and terminate the script for reasons that can confuse the author. [1]

[1] http://mywiki.wooledge.org/BashFAQ/105
[2] https://go.dev/doc/faq#exceptions