10 ms·

Depends on the app. In GUI, yes, why not, display an error message and you are done. In infrastructure software, OTOH, you want to handle errors in thoughtful m

Depends on the app. In GUI, yes, why not, display an error message and you are done. In infrastructure software, OTOH, you want to handle errors in thoughtful manner. If you can't it's often better to crash the application than to continue with broken state.

masklinn 9y ago
Erlang/Elixir is pretty interesting there in that it will "crash the application" but said application's scope is a single process (unless others are linked to it, which lets you build supervision tree and take down and restart the entire tree when one of the processes crashes).
fnord123 9y ago
Sure, if you're in a GUI then you report to the user that an operation failed and it's up to them to figure out what they can do about it. As for infrastructural software, yes you want to handle errors in a more thoughtful manner. If you can't and the process has corrupted it's own stack or heap (in the case of C or C++) then sure, abort. But I'm saying this line is often chucked over to "log the exception and do nothing" too quickly because it's often the easier thing to do. 25% of catastrophic failures in this one study appear to occur because of this. tl;dr: The devil is in the "If you can't".
- rumcajz 9y ago
  Yep. And lack of exceptions in languages like C or Go makes it harder to pretend you have done the right thing, if you in fact did not, given that it forces you handle every single error condition explicitly.
  - fnord123 9y ago
    Yes, exactly.
  - deleted 9y ago
    [deleted]
fiddlerwoaroof 9y ago
I think the distinction between errors (bugs) and exceptional situations made here[1] is important: if you have a problem because of some transient condition (an exceptional situation like a network outage or a full filesystem) then it makes sense to try to recover somehow. If you hit an error (i.e. A programming error or a bug) all you can do is abort, since you can no longer trust that the program will do the right thing. [1]: http://joeduffyblog.com/2016/02/07/the-error-model/ http://joeduffyblog.com/2016/02/07/the-error-model/

masklinn 9y ago

Erlang/Elixir is pretty interesting there in that it will "crash the application" but said application's scope is a single process (unless others are linked to it, which lets you build supervision tree and take down and restart the entire tree when one of the processes crashes).

fnord123 9y ago

Sure, if you're in a GUI then you report to the user that an operation failed and it's up to them to figure out what they can do about it. As for infrastructural software, yes you want to handle errors in a more thoughtful manner. If you can't and the process has corrupted it's own stack or heap (in the case of C or C++) then sure, abort. But I'm saying this line is often chucked over to "log the exception and do nothing" too quickly because it's often the easier thing to do. 25% of catastrophic failures in this one study appear to occur because of this. tl;dr: The devil is in the "If you can't".

rumcajz 9y ago
Yep. And lack of exceptions in languages like C or Go makes it harder to pretend you have done the right thing, if you in fact did not, given that it forces you handle every single error condition explicitly.
- fnord123 9y ago
  Yes, exactly.
- deleted 9y ago
  [deleted]

fiddlerwoaroof 9y ago

I think the distinction between errors (bugs) and exceptional situations made here[1] is important: if you have a problem because of some transient condition (an exceptional situation like a network outage or a full filesystem) then it makes sense to try to recover somehow. If you hit an error (i.e. A programming error or a bug) all you can do is abort, since you can no longer trust that the program will do the right thing. [1]: http://joeduffyblog.com/2016/02/07/the-error-model/ http://joeduffyblog.com/2016/02/07/the-error-model/