> Swift does not AFAICT provide mechanisms for enforcing checks of return types
Swift does this by default! You have to annotate (via @discardableResult) those functions which should not warn.
But of course try/catch is used in Swift more often.
Swift does this by default! You have to annotate (via @discardableResult) those functions which should not warn.
But of course try/catch is used in Swift more often.
While I have your attention: A big thank you for Fish shell!
And related to the current subject: How does fish handle errors? A quick skim found some constants that are returned upon failure, such as this case for disown: https://github.com/fish-shell/fish-shell/blob/master/src/bui...
What trade-offs did you face when designing error handling for your shell?
Shells are rarely CPU bound, so some perf overhead is acceptable. But shells may be used to recover badly broken systems. If fork or pipe fails, most programs are OK to abort, but a shell may be the user's last hope, so has to keep going.
For example, if pipe() fails, it's probably due to fd exhaustion. If your system is in that state, the best thing to do is immediately unwind whatever is executing, and put the user back at the prompt. fish uses ad-hoc error codes (reflecting its C legacy) instead of exceptions, though it uses RAII for cleanup. Your question made me realize that fish needs a better abstraction here; at least use `nodiscard`.
The story is different for script errors [1]. If the user forgets to (say) close a quote in a config file, fish will print the line, a caret, and a backtrace to the executing script. A lot of effort has gone into providing good error messages with many special cases detected. The parser also knows how to recover and keep going; I think Fabien would approve.
1: https://github.com/fish-shell/fish-shell/blob/225470493b3cd1...
I would be interesting to do a follow-up to this post where I compare the error handling for some common libraries/programs and ask the authors on what trade-offs the faced when designing error handling. It's a subject, I beliveve, that is often overlooked.
FWIW I find actual exception usage rare aside from automatic error out parameter to exception conversion by the Clang importer when bridging to Objective-C code.