The expected/unexpected distinction assumes you have the capacity to anticipate failures in the first place. But that capacity varies - even among experienced developers, everyone has blind spots shaped by their specific history. What's "obviously expected" to one senior dev is a surprise to another. The article's model is useful, but there's a prerequisite it doesn't address: the ability to expect is itself unevenly distributed.
Two kinds of error
11–20 of 24 posts
Re: Two kinds of error
#12I don't really like this article. There isn't anything particularly noteworthy to noticing that some computations have outcomes that allow some form of recovery, and other outcomes do not.
But there are some obvious follow up questions that I do think need better answers:
Why is recovery made so hard in so many languages?
Error recovery really feels like an afterthought. Sometimes that's acceptable, what with "scripting" languages, but the poor ergonomics and design of recovery systems is just a baffling omission. We deserve better options for this type of control flow.
Also, why do so many languages make it so hard to enumerate the possible outcomes of a computation?
Java tried to ensure every method would have in its signature how it could either succeed or fail. That went so poorly we simply put everything under RuntimeException and gave up. Yet resilient production grade software still needs to know how things can fail, and which failures indicate a recoverable situation vs a process crash+restart.
Languages seem to want to treat all failures as categorically similar, yet they clearly are not. Recovery/retry, logging, and accumulation all appear in the code paths production code needs to express when errors occur.
Following programming language development the only major advancements I've noticed myself have been the push to put more of the outcomes into the values of a computation and then further use a type system to constrain those values. That has helped with the enumeration aspect, leaving exceptions to mainly just crash a system.
The other advancement has been in Algebraic Effects. I feel like this is the first real advancement I've observed. Yet this feature is decried as too academic and/or complex. Yes, error handling is complex and writing crappy software is easy.
Maybe AI will help us get past the crabs at the bottom of the bucket called error handling.
Re: Two kinds of error
#13This sounds very neat in theory, but in practice errors are a continuum between these two extremes and there isn't really a clean dividing line.
Re: Two kinds of error
#14I was expecting Type I & II from statistical theory:
"Type I error, or a false positive, is the incorrect rejection of a true null hypothesis in statistical hypothesis testing. A type II error, or a false negative, is the incorrect failure to reject a false null hypothesis"
Re: Two kinds of error
#15If you're writing code professionally, then you're not in college anymore and your programs aren't simple things that run from the start of main() through to the end and then exit.
If you're providing a service that needs to keep running, you need a strategy for handling unexpected errors. It can be as simple as "fail the request" or "reboot the system", or more complicated. But you need to consider system requirements and the recovery strategy for meeting them when you're writing your code.
Long, long ago I worked with some engineers who thought it was just fine that our big piece of (prototype) telecom equipment took half an hour to boot because of poor choices on their part. Target availability for the device was 5 9s, which is 5 minutes of downtime per year. They didn't seem to realize the contradiction.
Re: Two kinds of error
#16It's common that if you extract a function or a module with a well defined interface, that function or module can't tell whether a "bad" input indicates an expected or an unexpected error. For example division by zero often indicates an "unexpected" error, but it wouldn't if you were implementing a spreadsheet. So to me the approach of using different forms of error reporting for the two kinds of error doesn't seem p…
That's a deficit of most programming languages. One solution is to pass every error value up and let the caller decide. Rust does this to some extent. This leads to verbose code however.
For modules inside your application, designing a good interface involves exposing the right errors and crashing for the rest. This creates some coupling of course (shared assumptions of which errors need to be handled across modules). Trying to avoid that probably just leads into the circle of hell where you have more abstract beancounting than useful code.
In the end, this is another reason why overreliance on external libraries leads to mediocre, buggy software.
Re: Two kinds of error
#17If you're writing code professionally, then you're not in college anymore and your programs aren't simple things that run from the start of main() through to the end and then exit. If you're providing a service that needs to keep running, you need a strategy for handling unexpected errors. It can be as simple as "fail the request" or "reboot the system", or more complicated. But you need to consider system requiremen…
> If you're writing code professionally, then you're not in college anymore and your programs aren't simple things that run from the start of main() through to the end and then exit.
Or you’re developing a CLI-biased app.
Plenty of "die" over yonder.
Re: Two kinds of error
#18> Expected: user enters invalid data
> Unexpected: function must be called with a non-empty string, and someone didn't
These seem like the same thing, I don't get why they are treated differently.
Re: Two kinds of error
#19I don't think that this simplification is useful. In the context of a user, crashing a program is a very disruptive process. Crash enough times, and a retail user might just ask for a refund, or move a corporate process to get rid of the program. Some errors won't happen with the same repro case, e.g. a memory leak, handling that is hard.
Re: Two kinds of error
#20This is the same distinction and motivation that led to Java's checked exceptions vs RuntimeException. It seemed like a good idea to enforce at the language level to handle what the author calls "known" errors, but treat "unknown" ones more leniently.
It led to a lot of boilerplate and as far as I know with hindsight it's seen as a bad design choice because the line is not so clear to draw.
As a first-order approximation it's good to learn about though, if you haven't heard about the concept. But I'd say this idea is introduced usually in the first programming course in an undergraduate college program.