Hacker News Reader

Comment by javajosh | Hacker News Reader

Checked exceptions are used to make up for Java's inability to return more than one value, plus it's inability to wrap two values without defining a new type. In other words, I think checked exceptions are basically a symptom of a lack of object literal syntax. This is in addition to their status as a "cool language feature" that is a siren song to new, bright programmers looking to spice up their designs. Exceptions are in general problematic (they move the program counter in a disjoint way - "non-local change of control" I think it's called) so it makes this particular siren song doubly deadly.

It would probably be handy if someone wrote a pamphlet on "Refactoring Exceptions" to give teams the confidence to refactor exceptions out of their code. I'll offer $20 to Martin Fowler to write such a thing.

View on HN

Exceptions “don’t move the program counter in disjoint ways”, they are part of the “structured gotos”. In fact, it has the same control flow as an early return does, with the handler being locally found in a parent’s (recursively) method body.

Also, the point about multiple return types is pointless — it already has Optional, a proper Return type is completely feasible to implement and use in Java. So is a Pair<A,B> if tuples are what you mean. Some are just not part of the standard lib by default.

>with the handler being locally found in a parent’s (recursively) method body

Yeah, that doesn't sound disjoint /s

That’s the exact same thing as if you had a function call as the last statement in a functional call as a last statement, etc. Literally just popping off stackframes.

Popping 1 stack is a normal return; popping N stacks is precisely what is meant by "no-local (or disjoint) transfer of control".

It pops one stack at a time only. It’s up to that function call to determine how to proceed further, the exact same way how it would happen with a last-call-chain I was talking about.

> Return type is completely feasible to implement

Yet it is rarely done. Lots of boilerplate to replace what is easily done in other languages. If java provided a native tuple type, new patterns would appeat. As it is, too many lines for 1 off returns. Send off a serialzed json and deserialize it later. Easier than specific dtos.

But the issue about the multiple return types is not pointless at all: Optional types, and pair types, were added to the language way later than checked exceptions. We didn't even have actual generics back then! So the checked exceptions really were a way to get around lacking alternative error management features.

If backwards compatibility wasn't a concern, checked exceptions would probably go away in a version or two, and we'd have some kind of monadic error type instead. But Java takes this seriously, and the standard library itself has methods with checked exceptions, so the timeline to go from checked exceptions to something else is very long.

FYI: With Java 21 (2023/09/19) this is finally possible.

Relevant JEPs:

- 441: Pattern Matching for switch

- 440: Record Patterns

- 409: Sealed Classes

- 395: Records

It is kind of similar to Scalas version of pattern matching with case classes.

And it won't get adopted any time soon due to backwards compatibility and existing code. Anybody who wanted to use it used vavr at this point.

Just came to say this. I think the best way to represent failure is in the return type, but Java made that very cumbersome and noisy.

Reply on news.ycombinator.com