3 ms·
Can you be more specific in how handling errors is difficult? I've found it to be generally forced and explicit, which, while sometimes unpleasant, is quite com
by ihsw 12y ago
Can you be more specific in how handling errors is difficult? I've found it to be generally forced and explicit, which, while sometimes unpleasant, is quite comforting.
The alternative seems to be exceptions flying unhinged.
- masklinn 12y ago> The alternative seems to be exceptions flying unhinged. … The commenter you replied to explicitly mentioned Erlang and Elixir, you may want to have an idea about where they're coming from before replying to their comment.
- ihsw 12y agoYeah, that's why I said seems. I'm not going to lie, I know next to nothing about Erlang and Elixir.
- MCRed 12y agoLet it fail, let it fail, let it fail! (to the tune of "let it snow, let it snow, let it snow!) Supervisor Trees! Exceptions are not much better, but checking the return every time is no fun. And if you crash the whole thing crashes. In erlang you can have a once in 1x10^9 error and not even catch it, but only that process crashes (and your system keeps running) and that process gets relaunched. With go, it's the whole program that will crash, necessitating checking every return value. I say this, though I might be missing some error handling system in go that I'm simply not aware of.
- falcolas 12y agoYou can set a `defer recover()` which will stop the panic from crashing the entire program, letting you recover & take whatever action you deem appropriate.