Exception Handling in Functional Interfaces

In a previous post, I have described what a functional interface is. In the same post, I explained that lambda-expressions can be used at any place a functional interface is used and gave an example for doing so.

One issue with using functional interfaces introduced under Java 8 is that functional interfaces don’t allow checked exceptions. In this post will discuss a way that will be able to fix this problem sometimes.

Note: The same solution that I’m going to present cannot be applied to all functional interfaces. You need to implement a variation of this to suit the functional interface you are dealing with.

So what is a checked exception?

Also known as compile-time exceptions, checked exceptions arise at compile time. These exceptions cannot be ignored and must be taken care of (handled) in order to compile the code.

For example, when creating a FileReader instance for reading streams of characters, the constructor requires you to handle the FileNotFoundException exception that will be thrown if the file does not exist or it cannot be opened for reading. Therefore the compiler will prompt the Programmer to handle this exception.

Functional Interfaces and Checked Exceptions:

Functional interfaces stated in the Java Language Specification do not allow for checked exceptions. That is, in the method declarations of functional interfaces throwing an exception is not supported.

Let’s see an example:

Suppose you want to read the password stored in text format from a file using a Supplier<String> instance and later print it out. As expected, opening the file for reading throws an IOException.

Notice that I have used a lambda expression syntax to declare the functional interface instance fileContents.

However, the above code results in a compile-time error message in the form of “Error:java: unreported exception java.io.IOException; must be caught or declared to be thrown”

This is because the T get( ) method of Supplier<T> functional interface just gets a result of type T and does not support throwing an exception. As such, the java.io.IOException that could be thrown when the file does not exist or it cannot be opened for reading is not supported by the get() method.

What we can do to avoid such a situation is to make use of functional interfaces whose methods allow checked exceptions, such as Callable<T> instead of Supplier<T>. This is possible because a Callable<T> has a method that is declared as T call() throws Exception, hence a Callable<T> instance is able to compute a result of type T or throw an exception if unable to do so. If we can have a Supplier<T> instance that can also exhibit properties of Callable<T> that would be ideal. To do that, I have declared the unchecked method in the Wrapper class shown below.

This solution above takes the form of a generic wrapper. A Callable<T> instance is wrapped in a Supplier<T> container to support throwing a checked exception.