Java 8 Friday: Better Exceptions

Posted on by lukaseder
At Data Geekery, we love Java. And as we’re really into jOOQ’s fluent API and query DSL, we’re absolutely thrilled about what Java 8 will bring to our ecosystem.

Java 8 Friday

Every Friday, we’re showing you a couple of nice new tutorial-style Java 8 features, which take advantage of lambda expressions, extension methods, and other great stuff. You’ll find the source code on GitHub.

Better Exceptions

I had the idea when I stumbled upon JUnit GitHub issue #706, which is about a new method proposal: 

ExpectedException#expect(Throwable, Callable)
One suggestion was to create an interceptor for exceptions like this. 

assertEquals(Exception.class, 
    thrown(() -> foo()).getClass());
assertEquals("yikes!", 
    thrown(() -> foo()).getMessage());
On the other hand, why not just add something completely new along the lines of this? 

// This is needed to allow for throwing Throwables
// from lambda expressions
@FunctionalInterface
interface ThrowableRunnable {
    void run() throws Throwable;
}

// Assert a Throwable type
static void assertThrows(
    Class<? extends Throwable> throwable,
    ThrowableRunnable runnable
) {
    assertThrows(throwable, runnable, t -> {});
}

// Assert a Throwable type and implement more
// assertions in a consumer
static void assertThrows(
    Class<? extends Throwable> throwable,
    ThrowableRunnable runnable,
    Consumer<Throwable> exceptionConsumer
) {
    boolean fail = false;
    try {
        runnable.run();
        fail = true;
    }
    catch (Throwable t) {
        if (!throwable.isInstance(t))
            Assert.fail("Bad exception type");

        exceptionConsumer.accept(t);
    }

    if (fail)
        Assert.fail("No exception was thrown");
}
So the above methods both assert that a given throwable is thrown from a given runnable – ThrowableRunnable to be precise, because most functional interfaces, unfortunately, don’t allow for throwing checked exceptions. See this article for details. We’re now using the above hypothetical JUnit API as such: 

assertThrows(Exception.class, 
    () -> { throw new Exception(); });

assertThrows(Exception.class, 
    () -> { throw new Exception("Message"); },
    e  -> assertEquals("Message", e.getMessage()));
In fact, we could even go further and declare an exception swallowing helper method like this: 

// This essentially swallows exceptions
static void withExceptions(
    ThrowableRunnable runnable
) {
    withExceptions(runnable, t -> {});
}

// This delegates exception handling to a consumer
static void withExceptions(
    ThrowableRunnable runnable,
    Consumer<Throwable> exceptionConsumer
) {
    try {
        runnable.run();
    }
    catch (Throwable t) {
        exceptionConsumer.accept(t);
    }
}
This is useful to swallow all sorts of exceptions. The following two idioms are thus equivalent: 

try {
    // This will fail
    assertThrows(SQLException.class, () -> {
        throw new Exception();
    });
}
catch (Throwable t) {
    t.printStackTrace();
}

withExceptions(
    // This will fail
    () -> assertThrows(SQLException.class, () -> {
        throw new Exception();
    }),
    t -> t.printStackTrace()
);
Obviuously, these idioms aren’t necessarily more useful than an actual try .. catch .. finally block, specifically also because it does not support proper typing of exceptions (at least not in this example), nor does it support the try-with-resources statement. Nonetheless, such utility methods will come in handy every now and then.

Next week

Stay tuned for more Java 8 goodness on this blog when we continue our Java 8 Friday series with great new examples.

Published by lukaseder

I made jOOQ

8 thoughts on “Java 8 Friday: Better Exceptions”

  1. What in the heck does:

    thrown(() -> foo())

    mean? You never defined foo(). This is why I’m not a fan of lambdas. It is all-too-easy to make them unreadable.

    Reply

    1. foo() in that GitHub issue appears to be the method that is being tested. So, thrown(() -> foo()) would probably run the lambda and catch exceptions in order to return them:

      static Throwable thrown(ThowableRunnable runnable) {
    try {
        runnable.run();
        return null;
    }
    catch (Throwable t) {
        return t;
    }
}

      In my opinion, this is a little less elegant than my own suggestion, as this would need to return null if no exception was thrown. Which would then again result in an exception at the call-site.

      This is why I’m not a fan of lambdas. It is all-too-easy to make them unreadable.

      Don’t be a hater now :-). It’s foo() that makes things unreadable, not lambdas. Here’s an example of an unreadable, non-functional foo()

      public BarBaz foo() {
    return bar(baz());
}
      Reply

Leave a Reply