Handling checked exceptions in lambda expressions can often be 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 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 T in "<T extends Throwable>" is generously inferred to be a RuntimeException.

This was originally intended to, for example, solve the ambiguous problem of inferring checked exception types 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 the compiler's back:

@SuppressWarnings("unchecked")
static <T extends Exception, R> R sneakyThrow(Exception t) throws T {
    throw (T) t; // ( ͡° ͜ʖ ͡°)
}

And indeed, the following works as un expected:

sneakyThrow(new IOException());

The boundary line between checked and unchecked exceptions does not exist at runtime, so everything works normally when running the code.

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 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(unchecked(ThrowingFunctionTest::throwException));

Instead of:

Optional.of(42)
  .map(i -> { 
      try { 
          return throwException(i); 
      } catch (IOException e) { 
          // ...
      }
});

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

This concept  hack 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.