Error (and Other Condition) Handling

Two big challenges of programming are 1) resource management and 2) variant condition handling. Traditionally, we’ve focused on the specific variants of 1′) memory management and 2′) error handling because they are omnipresent cases. One nice thing in the recent renaissance on resource management is that the focus has generalised a lot to all sorts of resources (eg file descriptors). Less so in error handling though most exception systems actually handle all sorts of conditions and, given their pervasiveness in modern object oriented languages, often have interesting specialisations of their exceptions.

I estimate that there are three major eras of resource management: manual (only), garbage collection dominance, and the emerging RAII/scope based approaches. Rust (following C++) are the current champions though I doubt GC is going anywhere. (And I’m eliding virtual memory, memory mapped files, and so on.)

We currently are seeing a fair bit of language level experimentation with error handling. Consider that neither Go nor Rust have exceptions. One interesting place where the two managements bridge is Null vs option types.

While the dangers of null are well known (the worst mistake in computer science), I’m not yet sold on option types or error code checking in general.

The main grand challenge of memory management is how to make memory seem infinite and uniformly accessible while 1) being super efficient and 2) not pestering the programmer too much.

The main grand challenge of error handling is how to ensure that all errors (or variant conditions) are handled without 1) making the main line of the program obscure, 2) destroying the ability of the programmer to reason able the program, and 3) making the program robust. The big problem is that all solutions involve a ton of clutter. Exceptions try to reduce some of the clutter at the cost of making control flow extremely non local.

Part of the problem is that there’s so many types of error and error-situation combos and so many ways of handling them and handling them “appropriately” that it’s genuinely difficult to get a basic much less systematic handle on things.

I don’t have any firm ideas where to go with all this. I have an intuition that tooling could help a lot. One simple thing would be to see what errors are known to be possible at a given bit of code. Java’s checked exceptions, I think, are meant to help with that but it’s too much manual crap and too easy to escape. We want exception inference.

Similarly, we need ways to see all the sites and sources and handling of a condition. In general, lots of conditions are cross cutting and handing a hierarchy of throws is just super confusion. We want to cluster a throw by similarity of situation and appropriate handling.

I’m not sure any linear/lexical approach is going to work. It’s intimately related to testing and we need modular ways to manage t