Handling checked exceptions in lambda expressions is often frustrating. Luckily, there is a type inference rule that we can exploit…<\/p>\n
While reading through the Java Language Specification<\/a>, we can find an interesting information:<\/p>\n A bound of the form “throws \u03b1<\/em>” is purely informational: it directs resolution to optimize the instantiation of “\u03b1”<\/em> so that, if possible, it is not a checked exception type. (…) Otherwise, if the bound set contains “throws \u03b1i”, and the proper upper bounds of “\u03b1i” are, at most, Exception, Throwable, and Object, then Ti = RuntimeException. Which simply means that every “throws<\/em> T<\/em>” will be generously inferred to a RuntimeException.<\/em><\/strong><\/p><\/blockquote>\n This was originally intended to e.g. solve the ambiguous problem of inferring checked exceptions from empty lambda expression bodies.<\/p>\n 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:<\/p>\n And indeed – the following works as The boundary line between checked and unchecked exceptions does not exist at runtime, so everything works normally.<\/p>\n 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?<\/p>\n First, we’d need a functional interface that represents a function that throws an Exception:<\/em><\/p>\n And now we could write an adapter method for converting it to the java.util.function.Function<\/em> instance:<\/p>\n 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:<\/p>\n And now, we no longer need to try-catch exceptions in lambda expressions:<\/p>\n And we can simply write:<\/p>\n As expected, Sneaky Throws is a double-edged sword.<\/p>\n 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<\/a>)<\/p><\/blockquote>\n 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:<\/p>\n 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>.<\/p>\n A number of libraries utilize this approach. For example, Lombok<\/a> and Vavr<\/a>.<\/p>\n@SuppressWarnings(\"unchecked\")\r\nstatic <T extends Exception, R> R sneakyThrow(Exception t) throws T {\r\n throw (T) t; \/\/ ( \u0361\u00b0 \u035c\u0296 \u0361\u00b0)\r\n}<\/pre>\nun<\/del>expected:<\/p>\nsneakyThrow(new IOException());<\/pre>\n
Unchecked Lambda Expressions<\/h2>\n
public interface ThrowingFunction<T, R> {\r\n R apply(T t) throws Exception;<\/pre>\nstatic <T, R> Function<T, R> unchecked(ThrowingFunction<T, R> f)<\/pre>\n
static <T, R> Function<T, R> unchecked(ThrowingFunction<T, R> f) {\r\n return t -> {\r\n try {\r\n return f.apply(t);\r\n } catch (Exception ex) {\r\n return ThrowingFunction.sneakyThrow(ex);\r\n }\r\n };\r\n}<\/pre>\nOptional.of(42)\r\n .map(i -> {\r\n try {\r\n return throwException(i);\r\n } catch (IOException e) {\r\n e.printStackTrace();\r\n return null;\r\n }\r\n });<\/pre>\nOptional.of(42)\r\n .map(unchecked(ThrowingFunctionTest::throwException));<\/pre>\n
The Other Edge<\/h2>\n
try {\r\n sneakyThrow(new IOException());\r\n} catch (IOException e) { \/\/ exception is never thrown in corresponding try block\r\n e.printStackTrace();\r\n}<\/pre>\nSummary<\/h2>\n