Sneakily Throwing Exceptions in Lambda Expressions in Java

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.

You May Also Like

JBoss Envers and Spring transaction managers

I've stumbled upon a bug with my configuration for JBoss Envers today, despite having integration tests all over the application. I have to admit, it casted a dark shadow of doubt about the value of all the tests for a moment. I've been practicing TDD since 2005, and frankly speaking, I should have been smarter than that.

My fault was simple. I've started using Envers the right way, with exploratory tests and a prototype. Then I've deleted the prototype and created some integration tests using in-memory H2 that looked more or less like this example:

@Test
public void savingAndUpdatingPersonShouldCreateTwoHistoricalVersions() {
    //given
    Person person = createAndSavePerson();
    String oldFirstName = person.getFirstName();
    String newFirstName = oldFirstName + "NEW";

    //when
    updatePersonWithNewName(person, newFirstName);

    //then
    verifyTwoHistoricalVersionsWereSaved(oldFirstName, newFirstName);
}

private Person createAndSavePerson() {
    Transaction transaction = session.beginTransaction();
    Person person = PersonFactory.createPerson();
    session.save(person);
    transaction.commit();
    return person;
}    

private void updatePersonWithNewName(Person person, String newName) {
    Transaction transaction = session.beginTransaction();
    person.setFirstName(newName);
    session.update(person);
    transaction.commit();
}

private void verifyTwoHistoricalVersionsWereSaved(String oldFirstName, String newFirstName) {
    List<Object[]> personRevisions = getPersonRevisions();
    assertEquals(2, personRevisions.size());
    assertEquals(oldFirstName, ((Person)personRevisions.get(0)[0]).getFirstName());
    assertEquals(newFirstName, ((Person)personRevisions.get(1)[0]).getFirstName());
}

private List<Object[]> getPersonRevisions() {
    Transaction transaction = session.beginTransaction();
    AuditReader auditReader = AuditReaderFactory.get(session);
    List<Object[]> personRevisions = auditReader.createQuery()
            .forRevisionsOfEntity(Person.class, false, true)
            .getResultList();
    transaction.commit();
    return personRevisions;
}

Because Envers inserts audit data when the transaction is commited (in a new temporary session), I thought I have to create and commit the transaction manually. And that is true to some point.

My fault was that I didn't have an end-to-end integration/acceptance test, that would call to entry point of the application (in this case a service which is called by GWT via RPC), because then I'd notice, that the Spring @Transactional annotation, and calling transaction.commit() are two, very different things.

Spring @Transactional annotation will use a transaction manager configured for the application. Envers on the other hand is used by subscribing a listener to hibernate's SessionFactory like this:

<bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean" >        
...
 <property name="eventListeners">
     <map key-type="java.lang.String" value-type="org.hibernate.event.EventListeners">
         <entry key="post-insert" value-ref="auditEventListener"/>
         <entry key="post-update" value-ref="auditEventListener"/>
         <entry key="post-delete" value-ref="auditEventListener"/>
         <entry key="pre-collection-update" value-ref="auditEventListener"/>
         <entry key="pre-collection-remove" value-ref="auditEventListener"/>
         <entry key="post-collection-recreate" value-ref="auditEventListener"/>
     </map>
 </property>
</bean>

<bean id="auditEventListener" class="org.hibernate.envers.event.AuditEventListener" />

Envers creates and collects something called AuditWorkUnits whenever you update/delete/insert audited entities, but audit tables are not populated until something calls AuditProcess.beforeCompletion, which makes sense. If you are using org.hibernate.transaction.JDBCTransaction manually, this is called on commit() when notifying all subscribed javax.transaction.Synchronization objects (and enver's AuditProcess is one of them).

The problem was, that I used a wrong transaction manager.

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager" >
    <property name="dataSource" ref="dataSource"/>
</bean>

This transaction manager doesn't know anything about hibernate and doesn't use org.hibernate.transaction.JDBCTransaction. While Synchronization is an interface from javax.transaction package, DataSourceTransactionManager doesn't use it (maybe because of simplicity, I didn't dig deep enough in org.springframework.jdbc.datasource), and thus Envers works fine except not pushing the data to the database.

Which is the whole point of using Envers.

Use right tools for the task, they say. The whole problem is solved by using a transaction manager that is well aware of hibernate underneath.

<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager" >
    <property name="sessionFactory" ref="sessionFactory"/>
</bean>

Lesson learned: always make sure your acceptance tests are testing the right thing. If there is a doubt about the value of your tests, you just don't have enough of them,