4 ms·
>For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log
by fnord123 9y ago
>For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log + "sorry, try again").
You are correct that this is how it's often done - 9 out of 10 errors probably ARE "handled" by a central error handler. But this is an incorrect approach if the goal is a reduction of catastrophic errors.
In the following paper, "Simple Testing Can Prevent Most Critical Failures" (OSDI '14). the authors discuss how some catastrophic errors occur in distributed systems that they test (Cassandra, HBase, Redis, HDFS, MapReduce).
http://www.eecg.toronto.edu/~yuan/papers/failure_analysis_osdi14.pdf http://www.eecg.toronto.edu/~yuan/papers/failure_analysis_os...
Notably section 4.1: Trivial Mistakes in Error Handlers:
"""
Figure 5 further breaks down the mistakes into three categories: (i) the error handler ignores explicit errors; (ii) the error handler over-catches an exception and aborts the system; and (iii) the error handler contains “TODO” or “FIXME” in the comment.
25% of the catastrophic failures were caused by ignoring explicit errors (an error handler that only logs the error is also considered as ignoring the error). For systems written in Java, the exceptions were all explicitly thrown, whereas in Redis they were system call error returns.
"""
I haven't used Go much but I personally much prefer Rust's error handling which appears to be largely similar.
- rumcajz 9y agoDepends 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 agoErlang/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 agoSure, 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".
- fiddlerwoaroof 9y agoI 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/