The Second Great Error Model Convergence

And failing fast is very different than ignoring an error.

Yeah on this my experience using third party rust code is people often using unwrap to ignore. In a sense it's still failing fast but well... often it feels like it could have been recoverable in cases I hit. At least use expect with a little error message!!!

I get what you're saying about Go for the case where there's not a used return value, there Rusts warn on unused infra really shines in a way I think most linters would struggle with

Here's an example of the Go compiler erroring out: https://go.dev/play/p/Z0ztJdkBzgp

Of course, this doesn't catch 100% of bugs. But it does catch a fair number of unused errors, so it's not quite right to say that it doesn't even warn.

It's funny because it depending on the situation, I find myself at either extremes. In Python, I really want business logic to throw exception I can even group them and handle them later and I'm fine with try-except-finally. But when dealing with interfaces that use error codes, like REST APIs, I really want to get error codes and not raise on error codes. Why would I want to do exception handling when I already know what the error code is?! After some reflection, the kind of error handling you want to do, might be a function of how much context you need to fix the error vs how acceptable stopping the world to fix the exception is.

To me it's so obvious that the checked approach is the correct one that I could never understand the pushback. Maybe there was something particular to Java and other languages with similar types systems that made it awkward to work with checked exceptions (a lack of proper polymorphism, perhaps)? Or maybe my usage is so idiosyncratic that I didn't realise others didn't like it?

Since I'm a strongly typed functional programmer I want to make invalid behaviours unrepresentable, but since I'm a pragmatic engineer I don't want to pay a high conceptual cost for that. My Haskell effect system Bluefin lets me get the best of both worlds, for example this function takes a Bool and returns an Int or can throw A, B or C as an exception:

foo ::
    Exception A e ->
    Exception B e ->
    Exception C e ->
    Bool ->
    Eff e Int

One common way of describing this is that the Exception ex e arguments are "capabilities": they give foo the capability to throw an exception of type ex. Because they're simply function arguments (not things bolted on to the return type) it's trivial to compose functions that throw exceptions.

But suppose we look at it from the point of view of Anders Hejlsberg in the article linked from the OP. What if we want foo to throw an exception of type D too? Well, that would be a new argument, so pays exactly the same cost as adding any other new argument to a function and we ask ourselves the same question: why? Sometimes there's a good reason and we have to do it; sometimes there not and we hold ourselves back. But in either case it's just a normal question of program design, nothing to do with exceptions per se.

And if we think A, B and C is too many exceptions to keep track of? Well, again, it's a normal question of program design: do we want to bundle those three up into a product/record type/struct? We can if we want. They're just arguments! We can do this, and pass just one argument:

foo2 ::
    (Exception A e, Exception B e, Exception C e) ->
    Bool ->
    Eff e Int

Maybe you think that's cheating because there are still three different exceptions. OK, if we don't care about the difference between them, just convert them all to String

simplerFoo ::
      Exception String e ->
      Bool ->
      Eff e Int
simplerFoo ex b =
     handle (throw ex . show) $ \exa -> do
       handle (throw ex . show) $ \exb -> do
         handle (throw ex . show) $ \exc -> do
           foo exa exb exc b

That's the equivalent of what Anders Hejlsberg derides as "throws Exception That just completely defeats the feature". I don't think so! If you really don't want to distinguish between different sorts of exceptions just throw an error string that you can print or log. Don't bother trying to keep track of fine-grained error states that you're not going to distinguish in the end anyway.

See also https://hackage.haskell.org/package/bluefin/docs/Bluefin-Exception.html

The thing with error handling is that it is actually a hard, subtle and situation specific problem. On a surface level it seems simple and largely just an inconvenience. Developers like to think about the happy path, and happy path is the most common path, but then... real life happens and error handling turns out very important. So programming culture for decades has been bouncing around looking for some silver bullet global-optimum, which turned out not to be possible.

At least in Rust the error handling has been done in a synthesis-like (thesis - error values, anthitesis - exceptions) middle ground, open-ended way. The weakness of exceptions being implicit and thus easy to overlook was avoided, while the tediousness of error handling was attempted to be avoided with a very compact short-circuit operator. Error values can be both: enumerated or type-erased, also as a middle ground. The downside of all of this is that now the developer need to make somewhat nuanced and informed decision about the details of their error handling.

So my take would be that it's not things are converging, but that the industry learned and is no longer as naive about the problem, and the approaches taken are more subtle in their differences, and by necessity being "more in the middle".

A different take, which I happened across yesterday:

I've worked extensively in large codebases that use checked exceptions, unchecked exceptions, and Result types [...] The error handling story was essentially the same in all of these codebases: Errors could occur nearly anywhere [...] This experience was the most pleasant in the codebase that used unchecked exceptions.

https://www.reddit.com/r/programming/comments/1pvjtcb/comment/nw08ye9/

I prefer a world with both. Things like a transient network error, I'd prefer to handle via exceptions; things like a lookup in a container that can fail, a Result-style return value (or Try-functions with out parameters). The latter makes sense for lightweight error handling. The former makes sense for heavier error handling and stack traces built in.

Trying to shoehorn everything into either one results in compromises and poor ergonomics.

You can see this in API evolution in language ecosystems like OCaml and C# where certain operations used to throw, but now have APIs returning an optional, or boolean return with out params.