Hacker News Reader

Comment by ragnese | Hacker News Reader

I feel like I'm the only crazy person who thinks checked exceptions are better than unchecked exceptions. I've read all the arguments against them and they just don't resonate with me. "Oh. So you think it's okay that a dependency's method changed to throw a new exception, but you don't want to have to change your code? Sounds super lazy and risky to me..." When your dependency's logic changes, yours probably needs to, as well.

What really drives me nuts is when the same person shits on checked exceptions and then advocates for using a monadic return value. They're completely isomorphic. The only difference is in how it reads.

View on HN

Java is the only language that has checked exceptions AFAIK.

Checked exceptions just lead to interface pollution. You really don't know what type of exception can be thrown by an implementation of a facade when you are defining the facade. And so then you are forced to define a InterfaceOperationException and then force all callers to wrap their exceptions in this type. Even if you use an implementation that is exception-free, you are forced to catch.

Painful and elaborate ceremony for very little gain. Usually exception handling is centralised at a few places in the code. Catching exceptions at these areas and boundaries is the best place instead of littering handler code all over the code base.

Oracle has realised that checked exceptions are a mistake. None of the java functional interfaces declare checked exceptions. If your operation throws a checked exception, it cannot be used as a convenient method reference lambda. It does not decay into a standard functional interface. This alone is an ultra critical-strike against checked exceptions.

If a condition is so important that you need to declare it as a checked exception, it generally indicates it should have been be a return type or your functional granularity is large. And normal types, unlike exception types, are well-suited to generics.

Swift does have checked exceptions too (at least by my understanding of the term "checked exception"). In general I think Swift is more thoughtfully and elegantly designed than Kotlin, people usually say that they're very similar but I find Swift more pleasant read and write.

Yes and no. In Swift you have to mark if a function throws, but not WHAT the function throws.

The Java-style checked exception haters might see that as the best of all worlds.

I generally agree that Swift is a little nicer than Kotlin. I like the enums better than sealed classes, I like that Swift has value types.

The only think from Kotlin that I miss in Swift is the scoping methods: apply, with, let, also.

The difference is that monadic result types work properly with generics. You can't really use checked exceptions generically at all (simplest example: you can't pass a function that throws a checked exception as a callback function, unless you write multiple overloads of any function that takes a callback), which really limits your ability to reuse code.

> What really drives me nuts is when the same person shits on checked exceptions and then advocates for using a monadic return value. They're completely isomorphic. The only difference is in how it reads.

Is that true? I was under the impression that annotating a certain type of exception being thrown doesn't prevent other (i.e. unchecked) exception types from being thrown from a method. If that's true, then that's a pretty significant different between monadic returns and checked exceptions; in the former case, returning an unknown error type leads to a compiler error, but in the latter, it leads to a crash at runtime.

Unchecked exception can be thrown and cause a crash in both cases.

When designing C# Anders Heljsberg decided against following Java's checked exceptions. You can find his argument against in the interview from 2003 https://www.artima.com/intv/handcuffs.html

Reply on news.ycombinator.com