Handling checked exceptions in lambda expressions is often frustrating. Luckily, there is a type inference rule that we can exploit\u2026<\/p>\n
While reading through the Java Language Specification<\/a>, we can find an interesting information:<\/p>\n A bound of the form \u201cthrows \u03b1<\/em>\u201d is purely informational: it directs resolution to optimize the instantiation of \u201c\u03b1\u201d<\/em> so that, if possible, it is not a checked exception type. (\u2026) Otherwise, if the bound set contains \u201cthrows \u03b1i\u201d, and the proper upper bounds of \u201c\u03b1i\u201d are, at most, Exception, Throwable, and Object, then Ti = RuntimeException. Which simply means that every \u201cthrows<\/em> T<\/em>\u201d 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\u2019s possible to exploit that rule and create a util method that will allow us to rethrow checked exceptions behind compiler\u2019s back using a little trick:<\/p>\n And indeed \u2013 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\u2019s 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\u2019 bodies?<\/p>\n First, we\u2019d 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\u2019d simply create a new lambda that delegates the job to the old one but rethrows the exception in case it\u2019s 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\u2019t like the rules, doesn\u2019t 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. \u2013 Brian Goetz (source<\/a>)<\/p><\/blockquote>\n Besides the danger of having a leakage of exceptions, we can\u2019t catch exceptions using their type because of javac\u2019s \u201chelping\u201d 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 \u2013 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
un<\/del>expected:<\/p>\nsneakyThrow(new IOException());<\/pre>\n
Unchecked Lambda Expressions<\/h2>\n
public interface ThrowingFunction
static
static
Optional.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