The challenge with exceptions is there is zero indication at the call site that a function can throw. Does myFunc() throw? Only way to know is to dig down through the entire call stack. Meanwhile with (value, error)/Result etc. it's obvious right at the call site whether a function can potentially error or not.
It's the exact opposite
With the either functional approach you just move the error around, and when you can't deal with it anymore you don't even have the stacktrace to know what damn piece of code created the error in the first place
I really don't understand the hate for checked exceptions either. The only downside to me is that you're forced to deal with exceptions when trying to prototype some code. A compiler option to ignore checked exceptions would easily fix that.
If you want to use exceptions then checked exceptions or the equivalent seems like a more logical approach than allowing anything to throw anything at any time. Which exceptions a function can raise is a part of its interface, so it might as well be documented and/or automatically recognised as such.
However, this style probably requires both a carefully considered set of possible exception types and good tool support to work well for developers in practice. Clearly we’d like to have both of those things in any case, but I’m not sure the average Java programmer at the peak of the checked exception debate had either, and it’s almost always in the context of Java that I see checked exceptions being criticised.
If you are dealing with functions that can end up propagating many different types of exception under sufficiently unusual conditions and you don’t have easy ways to do things like inferring exception specs for higher-level functions calling them or separating or consolidating multiple exception types as needed when handling them, that seems like a recipe for frustration. It’s easy to imagine writing endless boilerplate lists of obscure exception types for every function and then having to maintain those across your whole codebase any time some widely-used low-level function changes its spec, which seems completely impractical to manage at scale without good language and tool support.
They do cause issues when you need to implement an interface which doesn't declare the exception but you have a checked exception which can't be handled at that point. Only real option then is to rethrow as an unchecked exception. For example an Iterator which may have an IOexception.
I still like them, but they aren't a panacea, at least as Java implements them.
Yup. I would love to have checked exceptions in C++. They seem like the best possibility, at least for a language that can't support the monadic pattern thoroughly.
