3 ms·

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

by kaba0 3y ago

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.

throw3823423 3y ago
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.
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 ago
  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.
  - javajosh 3y ago
    Popping 1 stack is a normal return; popping N stacks is precisely what is meant by "no-local (or disjoint) transfer of control".
    - kaba0 3y ago
      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.
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.

by kaba0 3y ago

throw3823423 3y ago

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.

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 ago
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.
- javajosh 3y ago
  Popping 1 stack is a normal return; popping N stacks is precisely what is meant by "no-local (or disjoint) transfer of control".
  - kaba0 3y ago
    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.

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.