You'd like to think that, but they can be caught and used just like other exceptions. The one caveat is that you can't force code to account for potential RuntimeException's. With things like an IOException, the code has to account for the possibility that the exception will be thrown.

So, they are a little different, but the tooling for them is pretty much the same, greatly diminishing the effect.

Yes, it is.

The article was interesting, as are all Joe's articles on Midori. Nonetheless the impression I got by the end of it is that they ended up in virtually the same place as Java, with a few minor tweaks that could be easily implemented on top of the existing Java/JVM toolchain.

They decided that the errors which in Java descend from Error should not be catchable and should abort the process. That's easy to do - just use an agent, classloader or other pre-verification step to verify that no class contains a try {} catch (Error e) {} type construct and then change the default exception handler to call System.exit() if such an exception propagates up to the top of a thread. Java scopes the failure domain to the thread instead of the process, because it runs in places with expensive processes. But on Midori your "process" is a bit closer to a thread anyway.

They ended up with Java style checked exceptions, with almost identical syntax, albeit a nice extension to allow generic propagation of errors through functions like map. It'd be nice indeed to have that everywhere.

The concept of a "keeper" is interesting, though I wonder how often it'd be useful.

I find "abort on error" as an un-overridable default to be too aggressive. I would have once agreed with this, but I'm not sure I agree with his dichotomy of "rapid app development people" and "must be reliable people". All devs want their software to be reliable. It's easy to implement abort-on-error in a language with classical exceptions: just forbid catching such errors anywhere with a lint or static analysis check, and then call System.exit().

But my experience testing out Kotlin over the past 12 months has been that the IDE plugin has been very buggy and throws exceptions frequently (it's got a lot better but is still not at the gold standard of the rest of the IDE yet) ... yet IntelliJ routinely recovers from these errors almost invisibly. I've yet to see any obvious corruption or problems caused by these exceptions. It seems like the IDE, although it's not exactly a nuclear power plant, is written in a very exception safe style and more often than not it can just catch an exception from inside a plugin and keep going, even though those exceptions invariably represent programming errors. It'd be a shame if the entire IDE restarted every time that happened. I probably wouldn't use Kotlin at all, if that was the case.

So I am tempted to say that actually, despite the theoretical problems, it's not really so hard for people to write apps that can recover from programmer errors in many cases and it's often useful to do so. In particular, it means you get a reportable stack trace, and crash reports that contain stack traces are infinitely more useful than "Segmentation fault".

I'd like to see some of Duffy's ideas make it into mainstream development. Kotlin has an almost identical approach to nullability as what he describes, with the same syntax and smart casting ability, except it uses !! instead of nonnull(). So that's a good start. It does not compile down to object wrappers, it does use real nulls so you cannot have a Foo?? type. It uses unchecked exceptions, with optional support for declaring them (for Java interop). There is a library that adds a Result<> type with helpers for auto-catching exceptions and converting them into return codes. IDE support for highlighting call sites that could throw exceptions would be great. OK, it's not syntax, but that's OK, I'll take the tradeoff of it being a bit harder to review code in non-IDE tools vs having to type "try X" everywhere.

Basically all it needs is a simple compiler flag that says "Treat catching Throwable/Error as an error" and then a default exception handler that calls System.exit() and you've got something close to Midori's approach.