[flakes]

Very true. Checked exceptions in Java are a form of function coloring problem for modern libraries.

Especially painful when using any of the functional style stream operations, like `map`, `filter`, etc, or any other higher order function library. Most take in the standard `Function` or `BiFunction` interface arguments, which will not support method referencing for anything which includes a checked exception as part of its signature.

[gpderetta]

But a better language would allow generalizing over exceptions. In pseudo C++:

  auto map(collection<T> C collection, function<T> F f) -> invoke_result<F, T> throws(invoke_exception<F, T>);

[TeMPOraL]

> Checked exceptions in Java are a form of function coloring problem for modern libraries.

So is returning result or error via Either/Expect/Result sum types. Exceptions or Expected, code gets messed up either way.

[flakes]

Not quite of the same caliber. A checked exception has the form `R func(T t) throws Err`. A concrete result type (like Rust has) would look like `Result<R, Err> func(T t)`.

The later fits nicely into the `Function<,>` interface, `Function<T, Result<R, Err>>` vs the former requires a different interface entirely, something like `FuncE<T, R, Err>` where `Err` breaks out into an argument for the throws value of the signature.

Because most of the functional libraries in Java work with Function, BiFunction, etc, we end up with incompatible arguments for common patterns such as `map`, `filter`, etc.