Java's checked exceptions aren't (usefully) polymorphic. You can't write, for example: R process<R, E extends Exception>(ThrowingFunction<Long, R, E> proce

Java's checked exceptions aren't (usefully) polymorphic. You can't write, for example: R process<R, E extends Exception>(ThrowingFunction<Long, R, E> processor) throws E { ... } You could write "process" to the Exception base class, but it still can't handle a "processor" that doesn't throw at all. Checked exceptions a "bolted on" effect that sits outside the usual type system in Java, and their presence on a method signature "colours" it in a way that an effect described inside a type system would not. More of a stain than a tint, if you will. Java 8 resolved it by quietly pretending checked exceptions never happened, which works fine until (1) you get unhandled unchecked exceptions in all their glory at runtime, and (2) you want to use one of the Java 7 or earlier methods as a "processor" but, oh no, it throws an exception. (It's a deeper colouring than JavaScript's async/await keyword, which is just syntactic sugar around continuations in callbacks and returning promises - you can pass an async "processor" function to a "process" function that has no idea what it's getting and get back the promise you'd expect from it.)