The problem with that is that checked exceptions ask you to be treated as normal (non-exceptional) control flow. Hence the appeal of unchecked exceptions because they allow you to treat exceptional control flow as exceptional. The comparison of checked exceptions with result types is because they are competing solutions for normal control flow.

In that other subthread, several problems are mentioned that occur even when you use checked exceptions only for exceptional control flow. The big ones that come to my mind are that functional-style methods like .map() and .filter() and the corresponding interfaces like Function<> and Predicate<> cannot deal with checked exceptions at all; the other (related) is that declared exception types cannot use type variables.

With result types, error handling becomes non-exceptional control flow and you can use .filter() and .map() to handle the error cases themselves. With Java's unchecked exceptions, error stay exceptional and the functional-style methods pass them on transparently. Checked exceptions cannot do either, and are incompatible with functional-style methods.

> Normally, Rusts exception handling is almost exactly isomorphic to checked exceptions in Java.

yes, that's the problem ahha