Comment by bcrosby95 | Hacker News Reader

Comment by bcrosby95 | Hacker News Reader

Parent Full thread

I think most complaints about checked exceptions in Java ultimately boil down to how verbose handling exceptions in Java is. Everytime the language forces you to handle an exception when you don't really need to makes you hate it a bit more.

First, the library author cannot reasonably define what is and isn't a checked exception in their public API. That really is up to the decision of the client. This wouldn't be such a big deal if it weren't so verbose to handle exceptions though: if you could trivially convert an exception to another type, or even declare it as runtime, maybe at the module or application level, you wouldn't be forced to handle them in these ways.

Second, to signature brittleness, standard advice is to create domain specific exceptions anyways. Your code probably shouldn't be throwing IOExceptions. But Java makes converting exceptions unnecessarily verbose... see above.

Ultimately, I love checked exceptions. I just hate the ergonomics around exceptions in Java. I wish designers focused more on fixing that than throwing the baby out with the bathwater.

If only Java also provided Either<L,R>-like in the standard library...

Personally I use checked exceptions whenever I can't use Either<> and avoid unchecked like a plague.

Yeah, it's pretty sad Java language designer just completely deserted exception handling. I don't think there's any kind of improvement related to exceptions between Java 8 and 24.

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?

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

Sure

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.

There is a major difference at the call site.

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

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

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.

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

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.

That’s the same conclusion I’ve come too. I’ve commented on it a little bit here:

https://news.ycombinator.com/item?id=44551088

https://news.ycombinator.com/item?id=44432640

> Your code probably shouldn't be throwing IOExceptions. But Java makes converting exceptions unnecessarily verbose

The problem just compounds too. People start checking things that they can’t handle from the functions they’re calling. The callers upstream can’t possibly handle an error from the code you’re calling, they have no idea why it’s being called.

I also hate IOException. It’s so extremely unspecific. It’s the worst way to do exceptions. Did the entire disk die or was the file not just found or do I not have permissions to write to it? IOException has no meaning.

Part of me secretly hopes Swift takes over because I really like its error handling.

There usually are more specific exceptions, at least when it's easy enough to distinguish the root cause from OS APIs. But it often isn't. A more practical concern is that it is not always easy to find out which type it is. The identity of the specific types might not be part of the public API interface, perhaps intentionally so.

Reply on news.ycombinator.com