No thanks. Anything that doesn't have error handling enabled by default goes straight in the trash bin.
No thanks. Anything that doesn't have error handling enabled by default goes straight in the trash bin.
The closest I could find is what you suggest (checking $?), or using something like this [1], which would require changing syntax:
system('ls -j', exception: true)
Would be great to know if there's some easy callback or, ideally, a global setting one can make so a ruby exception is thrown if there's an error running system commands using the backtick syntax.This isn’t true for Ruby nor shell scripts. In Ruby you have `system` or `Open3`. In shell scripts you:
if my_command
then
on_success
else
on_failure
fi
Shellcheck even warns you of that.I believe the author was talking about set -e (often used with -o pipefail), so that any unhandled error simply exits the script.
I don’t need to check the exit status of every command.
> I believe the author was talking about set -e (often used with -o pipefail), so that any unhandled error simply exits the script.
I have no idea how you could get that impression from the section I quoted.
How would setting one option once at the top of the script mean “Requiring the user to manually check $? after each command”?
Some would say calling out to shell is an anti pattern by itself. Others would say exceptions are an anti pattern. (Just use appropriate return type and there's no need for exceptions ever!)
There’s really no need for this kind of over-the-top response.
1. Make it difficult to ignore that a function can return an error. This is the golang approach. Errors are part of the return values and unused return values are compiler errors.
2. Make it impossible to use parts of the return value having an error state. Rust does this with the Result sum type and pattern matching.
3. Tailor for the happy-path and throw exceptions in case there are any errors. With optional means to catch them if recovering errors is desired. This is how most other languages function.
Hiding the error status in another variable, that is super easy to overlook and that the programmer might not even know exists, then continuing despite this variable not being checked will inevitably introduce bugs allowing faulty data in your system.