Away from Exceptions: Errors as Values

Because when it comes to exceptions there are really only 2 things you can do: abort the current operation or retry it.

The code generating the exception will know which of these is appropriate and the try/catch handler is what would restart or cancel the operation.

The exact details of the exception are for debugging not for program flow.

Of course, the implementation mechanism matters at the machine code level or in the runtime. However, that is mostly a question of performance trade-offs and interoperability, but otherwise just an implementation detail, and doesn’t have to be a question of expressiveness and code-level semantics. You can implement exceptions as subroutine return values, and you can implement error return values with exception-like mechanisms behind the scenes. That should be a different concern from how it looks like at the source-code level.

I program a lot in Java, and the only trouble there is the lack of support for sum types and/or variadic type parameters in generics (i.e. to express functional interfaces that can throw an arbitrary number of checked exceptions, as a type parameter). That’s the only pain point for me and is something that could be fixed.

In fact, the interplay with control structures is exactly what I was referring to by syntactic sugar. Indeed it also concerns the type system.

But let’s talk about that, not about exceptions good/bad or error values good/bad. That’s too simplisitic.

But the commenter I responded to seemed to me to be wishing for a language that explicitly disallows that. Maybe I misunderstood?

To even get out of static vs. dynamic typing, I've expressed the problem as "Given this piece of code, how can I know what types of errors will come out of it?", where I'm using a human, loosey-goosey sense of the word "type" here, rather than necessary a strict type. (If your language wants to answer that in terms of strict types, great, but I'm trying to answer it very generally across programming languages.) It turns out that from what I can see, the underlying problem is that "errors don't compose"; given a function f that returns errors X, Y, and Z and accepts another function f2 to call that may return other errors, it is really difficult to characterize f(f2) in practice. For a concrete, static f2 we can mostly at least imagine taking the union of the two (although even that can be an oversimplification; what if f calls f2 in such a way that one of the types of errors that f2 can produce is guaranteed not to happen, e.g., what if f2 could throw a null pointer exception but it can be easily statically proved that f never passes it one?), but once you let enough polymorphism into the mix to let f2 be an arbitrary closure of some type, all bets are off in terms of what f(f2) can produce in most languages.

This hurts statically-typed languages in that they can't create very strong types for these sorts of situations, but more generally, translating the theory up to practical experience regardless of the language being used, A: it's hard to program in an environment where you have enough polymorphism of some sort (OO, accepting closures, whatever) to have errors mix like this in your code and know what sort of errors may occur where and B: that's nearly everything because programming in an environment that lacks that polymorphism is not something we generally do voluntarily. (Embedded code not allowed to even allocate on the stack is this static, but we can't build everything that way.)

Amusingly, I think what saves us in the end is that to a first approximation, there is no such thing as error handling. All there is is logging something for a human and giving up. Obviously, to a second approximation there is a such thing as error handling. I've got plenty of it. But honestly, it's pretty rare by percentage. Most errors result in a log message and some level of failed task. Fortunately, with some work, we can usually get our systems fed enough good data that we can do things without errors, such that the ones that do occur end up almost always being essentially correctly handled by screaming and dying. If programming actually required us to handle errors, like, in some intelligent manner all the time, we'd have a lot fewer programs in the world!