FAQ

Why are the interfaces defined to throw Throwable? Why not just Exception?

Because some great candidates for lambdas throw that. One example is all the invocation methods of MethodHandles.

Why are you letting RuntimeExceptions slip through unchanged? Why not catch them?

It's a design choice from the author, who is a firm believer in checked exceptions and who, by consequence, sees unchecked exceptions as exceptions thrown to signal an unrecoverable situation; as such they should be "left alone".

This may change in the future; it is a fact that unfortunately a number of APIs throw unchecked exceptions where a checked exception would have been (again, in the author's view) more appropriate.

Will I be able to use it with my own methods/interfaces which throw exceptions?

If the signature of your method or interface is compatible with one of the Throwing* interfaces defined by this package, then yes. By signature, you should understand:

• the return type (if any; this can be void);
• the number of arguments, and their type.

The type, and number, of exceptions thrown by your method/interface does not matter; since all interfaces throw Throwable, "anything goes".

Why don't these interfaces implement Serializable?

"Serialization is, unquestionably, the worst language feature ever added to any language that made it out of the nursery [...] And it's the gift that keeps on giving".

This is not me saying it, it's Brian Goetz.

Long story short: a serializable @FunctionalInterface ruins linkage performance and most optimizations which make up the strength of lambdas. You may have noticed that none of the new @FunctionalInterfaces defined in Java 8 are Serializable.

Therefore, any request to make them Serializable will be rejected with a flat out "NO", and the link to the video above will be added to any and all such requests. And you should really watch the whole video anyway, not only Mr Goetz' rant ;)