Hacker News new | past | comments | ask | show | jobs | submit login

> 1. You aren't forced to write it. It's simply possible to forget that a function might fail (e.g. when that failure is defined as a side-effect).

When the compiler does require you to explicitly acknowledge exceptions (Java), people hate it.




People hate how Java did it. That's not the same as hating all possible expressions of the same idea.

That's true of a lot of good ideas that were poorly executed in Java.

Making it impossible to ignore potential errors is something I'm very happy to have as long as the tools for working with it are pleasant. Java's checked exceptions were decidedly unpleasant. Algebraic return types with combinators to work with them actually are pretty nice.


Yes, although I’ve never understood what the objection is. I’m sad that they removed checked exceptions from Kotlin (which is otherwise better than Java in almost every respect).

When used sparingly, checked exceptions are great, specifically because the compiler forces you to catch and handle exceptions.

Maybe if there were an easy to way to convert back and forth between checked exceptions and “Either” wrapper unions, that would fix the situations where checked exceptions are tedious or awkward to use. But I’ve honestly never felt that to be a problem, they’re fine.



Yes, when you’re putting a class with exceptions inside a generic container that doesn’t allow for exceptions, it gets ugly.

The solution in that blog post is clever, they should consider adding that to Java.

Although, as the author touches on but doesn’t explicitly call out, this problem can be avoided in current Java simply by adding (generic) exceptions to your generic classes. Unfortunately that hasn’t been done for any of the standard library classes, old or new.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: