>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.
Re:Why Checked Exceptions Failed
by Supermancho on Saturday July 15, 2023 @12:12PM
(#36738187)
> 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.
Re:Why Checked Exceptions Failed
by throw3823423 on Saturday July 15, 2023 @04:19PM
(#36740581)
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.
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.