Hacker News Reader

Comment by bertylicious | Hacker News Reader

Java has/had a compiler check that forced you to write catch blocks or `throws` annotations in/on functions that call other functions which might throw. The feature is called "checked exceptions" and I believe it has been discarded for its inconvenience by now.

Sometimes it feels like developers are going in circles while trying to find the most optimal way to handle errors.

View on HN

Checked exceptions are one of the main reasons I’m sticking with Java, even though Java lacks the ability to abstract over sets of checked exceptions, which does cause some inconvenience. It’s unfortunate that no other mainstream languages have been taking that approach.

That sounds awesome! Do you have that flag set on a big codebase? Was it a big hassle to turn it on (like you had to remediate a bunch of code that didn't handle exceptions before you could check it in). Have you seen any big changes since enabling it?

Checked exceptions in Java are the default state and much of the standard library uses them.

In languages with a Result type (or Either monad), you basically do have checked exceptions, even though the language has no exceptions.

Java also has that option. There is an excellent library called vavr. It adds the Try and Either monad to Java.

With result types, you typically don’t get automatic exception propagation. I agree that overall it’s a spectrum of syntactic convenience, checked exceptions effectively form a sum type together with the regular return type.

People are now realizing that having the errors a function can cause right in the type system may actually have been a good idea, but when you point out that Result is not the only way and that Java checked Exceptions do the exact same thing (and so does the Zig error handling mechanism which is a third variant of the idea), they come up with all sorts of easily dismissable nonsense to explain why the two are very different.

What would you reply to this comment:

https://news.ycombinator.com/item?id=37174698

I’m not the parent, but exception declarations are IMO necessary for a stable API contract. It’s exactly the same reason why return types are explicit. The actual issue in Java is that you can’t abstract over an arbitrary-length list (sum) of checked-exception types (variadic type parameters) (with the exception of rethrowing from multi-catch clauses).

Well, that's kind of true! The fact checked Exceptions are inconvenient doesn't change the fact they are equivalent to returning a Result type (the implementation is obviously different but I think we don't need to mention that).

A future version of Java could totally make it more convenient, and perhaps even make the implementation cheaper such that it would not just nearly the same , but literally the same as in Rust or other similar languages.

Does it even need a new language version? If the compiler already spits out the error "hey, your Fart() function should be annotated with 'throws ButtsException'", couldn't an IDE relatively easily be configured to automatically add the " throws " annotations?

Have you ever used Java?? Any half decent IDE has done that since 2000.

Never in anger - I've done some JVM coding, but always in Kotlin (which doesn't have checked exceptions).

If Java IDEs have been able to automatically take care of checked exceptions forever, then why do people say that they're inconvenient?

Because the people saying that usually do not program in Java.

After working with railway oriented programming with Arrow in Kotlin I had the same feeling of using checked exceptions.

And please make the Errors generically wrappable in order to avoid losing the traces.

Reply on news.ycombinator.com