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.

There is a major difference at the call site.

try/catch has significantly more complex call sites because it affects control flow.

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.

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

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