5 ms·

Ok please help me understand, what is the difference between - R method() throws L, and - Either<L, R> method() To me they seem completely isomorphic?

worldsayshi 1y ago
Don't you mean "isosemantic"? Since the same concept is represented with different syntax.
- alex_smart 1y ago
  Sure
  - worldsayshi 1y ago
    I point it out because I think the distinction is interesting. Can we build tools that helps us work with the boundary between isosemantic and isomorphic? Like any two things that are isosemantic should be translatable between each other. And so it represents an opportunity to make the things isomorphic.
cloogshicer 1y ago
There is a major difference at the call site. try/catch has significantly more complex call sites because it affects control flow.
- Jensson 1y ago
  That is just a syntactic sugar difference, you could have exactly the same call site structure if you wanted in a language.
lock1 1y ago
That's what I thought at first too. At first glance they look equivalent, telling API users what the expected result of a method call is. In that sense, both are equivalent. But after experimenting a bit with checked exceptions, I realized how neglected exceptions are in Java. - There's no other way to handle checked exceptions other than try-catch block - They play very badly with API that use functional interfaces. Many APIs don't provide checked throws variant - catch block can't use generic / parameterized type, you need to catch Exception or Throwable then operate on it at runtime After rolling my own Either<L,R>, it felt like a customizable typesafe macro for exception handling. It addresses all the annoyances I had with checked exception handling, and it plays nicely with exhaustive pattern matching using `sealed`. Granted, it has the drawback that sometimes I have to explicitly spell out types due to local type inference failing to do so. But so far it has been a pleasant experience of handling error gracefully.
xigoi 1y ago
Either allows you to do things like map, flatMap, getOrDefault, etc., whereas exceptions can only be handled via try/catch blocks.
pjmlp 1y ago
I would say one we are allowed to bash upon, forgetting the history of key programming languages with checked exceptions predating Java (CLU, Modula-3 and C++), whereas the other is the cool FP programming concept that everyone coding is coffee shops is supposed to find cool. Semantically from CS point of view in language semantics and type system modelling, they are equivalent in puporse, as you are very well asking about.

worldsayshi 1y ago

Don't you mean "isosemantic"? Since the same concept is represented with different syntax.

alex_smart 1y ago
Sure
- worldsayshi 1y ago
  I point it out because I think the distinction is interesting. Can we build tools that helps us work with the boundary between isosemantic and isomorphic? Like any two things that are isosemantic should be translatable between each other. And so it represents an opportunity to make the things isomorphic.

cloogshicer 1y ago

There is a major difference at the call site. try/catch has significantly more complex call sites because it affects control flow.

Jensson 1y ago
That is just a syntactic sugar difference, you could have exactly the same call site structure if you wanted in a language.

lock1 1y ago

That's what I thought at first too. At first glance they look equivalent, telling API users what the expected result of a method call is. In that sense, both are equivalent. But after experimenting a bit with checked exceptions, I realized how neglected exceptions are in Java. - There's no other way to handle checked exceptions other than try-catch block - They play very badly with API that use functional interfaces. Many APIs don't provide checked throws variant - catch block can't use generic / parameterized type, you need to catch Exception or Throwable then operate on it at runtime After rolling my own Either<L,R>, it felt like a customizable typesafe macro for exception handling. It addresses all the annoyances I had with checked exception handling, and it plays nicely with exhaustive pattern matching using `sealed`. Granted, it has the drawback that sometimes I have to explicitly spell out types due to local type inference failing to do so. But so far it has been a pleasant experience of handling error gracefully.

xigoi 1y ago

Either allows you to do things like map, flatMap, getOrDefault, etc., whereas exceptions can only be handled via try/catch blocks.

pjmlp 1y ago

I would say one we are allowed to bash upon, forgetting the history of key programming languages with checked exceptions predating Java (CLU, Modula-3 and C++), whereas the other is the cool FP programming concept that everyone coding is coffee shops is supposed to find cool. Semantically from CS point of view in language semantics and type system modelling, they are equivalent in puporse, as you are very well asking about.