If you were creating a new programming language from scratch, there’s no clear agreed answer to what error handling approach you should pick, not the way we have more or less agreed on how for, while, and so on should work.
I think that they don’t talk to enough language designers. Errors-as-values is the correct model because it eventually leads to the understanding that errors are our opinions about the state of the machine rather than an actual failure of the machine’s invariants, and the permanent divide between recoverable-yet-undesirable “error” states and genuine faults in the hardware. All other error models persist due to inertia and machismo.
This doesn’t mean that exceptions have to be removed from languages, but rather that we should think of them as continuation-passing or stack-controlling operations which perform non-local jumps; they’re part of the structured-control-flow toolbox along with break/return/continue jumps. Going in the other direction, a language designer need not add exceptions if they intend to add call/cc instead.
You’d be left to evaluate trade offs in language design and language ergonomics and to make (and justify) your choices, and there probably would always be people who think you should have chosen differently.
Yeah, but Sturgeon’s Law never stops; most new programming languages are fundamentally not interesting because they are either garbage-collected Algol-descended languages or memory-unsafe. Meanwhile, sum types can always be added to simply-typed lambda calculi without invalidating any safety properties. If you argue in favor of mediocrity, you’re gonna get Golang instead of something good.
threaded - newest
There are many reasonable approaches… it just so happens that Go’s is not one of them.
We had a post about error handling here recently: An epic treatise on error models in systems programming languages
As I write in a comment there, I can also recommend the referenced The Error Model which is a bit shorter and more concrete
With much more expansive exploration and reasoning, both come to the same conclusion as this post: It’s not a solved problem.
I think that they don’t talk to enough language designers. Errors-as-values is the correct model because it eventually leads to the understanding that errors are our opinions about the state of the machine rather than an actual failure of the machine’s invariants, and the permanent divide between recoverable-yet-undesirable “error” states and genuine faults in the hardware. All other error models persist due to inertia and machismo.
This doesn’t mean that exceptions have to be removed from languages, but rather that we should think of them as continuation-passing or stack-controlling operations which perform non-local jumps; they’re part of the structured-control-flow toolbox along with break/return/continue jumps. Going in the other direction, a language designer need not add exceptions if they intend to add call/cc instead.
Yeah, but Sturgeon’s Law never stops; most new programming languages are fundamentally not interesting because they are either garbage-collected Algol-descended languages or memory-unsafe. Meanwhile, sum types can always be added to simply-typed lambda calculi without invalidating any safety properties. If you argue in favor of mediocrity, you’re gonna get Golang instead of something good.