Thanks for the thoughtful response. I spent a bit of time thinking about it, and thank you for that as well. So, I think you're right about a result type being

Thanks for the thoughtful response. I spent a bit of time thinking about it, and thank you for that as well. So, I think you're right about a result type being isomorphic to checked exceptions, for the reasons you laid out. If you compare it to Rust, what ends up happening is similar -- many libraries return an error type that's a union of all their dependencies' error types, and binaries end up using an "everything" anyhow::Error type in the end. However, I think where sum types in general end up working and checked exceptions don't are: 1. Sum types don't encourage a mix of checked and unchecked exceptions the way Java does. Translating from Rust, all exceptions that are meant to be handled by regular users are checked. The only exceptions that are unchecked are broken invariants (panics), which usually end up being handled either through aborting the program or through some sort of top-level restart logic. You could write Java in that style but it's not the ecosystem's convention. 2. Sum types are more general than checked exceptions: they can be used to express nulls and business logic as well. I suspect checked exceptions would have worked better if Java also had nullable and non-nullable types, because nullability is such a common source of errors. 3. You're right that you can drop an error on the floor with sum types as well, just like an empty catch block with exceptions. But that just doesn't happen nearly as often in practice, because result types form a closed set. With checked exceptions, in practice you often end up with a method throwing both checked and unchecked exceptions, and the same syntax is used to handle both. I think checked and unchecked exceptions are fundamentally very, very different and mixing the two is a mistake. Once again, thank you for your response.