3 ms·
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. I
by javajosh 3y ago
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.
- dudul 3y agoJust 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.
- kaba0 3y agoExceptions “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.
- throw3823423 3y agoBut 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.
- javajosh 3y ago>with the handler being locally found in a parent’s (recursively) method body Yeah, that doesn't sound disjoint /s
- kaba0 3y agoThat’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.
- javajosh 3y agoPopping 1 stack is a normal return; popping N stacks is precisely what is meant by "no-local (or disjoint) transfer of control".
- kaba0 3y agoIt 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.
- Supermancho 3y ago> 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.
- spreiti 3y agoFYI: 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.
- isbvhodnvemrwvn 3y agoAnd 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.