> 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.
When the compiler does require you to explicitly acknowledge exceptions (Java), people hate it.
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.
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.
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.