Handling checked exceptions in lambda expressions is often frustrating. Luckily, there is a type inference rule that we can exploit…
Java 8 Type-Inference
While reading through the Java Language Specification, we can find an interesting information:
A bound of the form “throws α” is purely informational: it directs resolution to optimize the instantiation of “α” so that, if possible, it is not a checked exception type. (…) Otherwise, if the bound set contains “throws αi”, and the proper upper bounds of “αi” are, at most, Exception, Throwable, and Object, then Ti = RuntimeException. Which simply means that every “throws T” will be generously inferred to a RuntimeException.
This was originally intended to e.g. solve the ambiguous problem of inferring checked exceptions from empty lambda expression bodies.
And now, it’s possible to exploit that rule and create a util method that will allow us to rethrow checked exceptions behind compiler’s back using a little trick:
@SuppressWarnings("unchecked")
static <T extends Exception, R> R sneakyThrow(Exception t) throws T {
throw (T) t; // ( ͡° ͜ʖ ͡°)
}
And indeed – the following works as unexpected:
sneakyThrow(new IOException());
The boundary line between checked and unchecked exceptions does not exist at runtime, so everything works normally.
Unchecked Lambda Expressions
Since it’s possible to rethrow checked exceptions as unchecked, why not use this approach for minimizing the amount of boilerplate used when dealing with aching exceptions present in lambda expressions’ bodies?
First, we’d need a functional interface that represents a function that throws an Exception:
public interface ThrowingFunction<T, R> {
R apply(T t) throws Exception;
And now we could write an adapter method for converting it to the java.util.function.Function instance:
static <T, R> Function<T, R> unchecked(ThrowingFunction<T, R> f)
Inside the implementation, we’d simply create a new lambda that delegates the job to the old one but rethrows the exception in case it’s raised:
static <T, R> Function<T, R> unchecked(ThrowingFunction<T, R> f) {
return t -> {
try {
return f.apply(t);
} catch (Exception ex) {
return ThrowingFunction.sneakyThrow(ex);
}
};
}
And now, we no longer need to try-catch exceptions in lambda expressions:
Optional.of(42)
.map(i -> {
try {
return throwException(i);
} catch (IOException e) {
e.printStackTrace();
return null;
}
});
And we can simply write:
Optional.of(42) .map(unchecked(ThrowingFunctionTest::throwException));
The Other Edge
As expected, Sneaky Throws is a double-edged sword.
Just because you don’t like the rules, doesn’t mean its a good idea to take the law into your own hands. Your advice is irresponsible because it places the convenience of the code writer over the far more important considerations of transparency and maintainability of the program. – Brian Goetz (source)
Besides the danger of having a leakage of exceptions, we can’t catch exceptions using their type because of javac’s “helping” hand which is a clear loss of flexibility:
try {
sneakyThrow(new IOException());
} catch (IOException e) { // exception is never thrown in corresponding try block
e.printStackTrace();
}
Summary
The concept of sneaky throws has been around for a couple of years but with a new Type Inference rule, it became much cleaner to execute – which can be particularly handy when dealing with exceptions and lambda expressions but it has its price.
A number of libraries utilize this approach. For example, Lombok and Vavr.
Code snippets can be found on GitHub.
