Lazy Error Handling in Java, Part 3: Throwing Away Throws

In parts 1 and 2, I covered how we could create first-class functions in Java that declare, in their types, the exceptions they might throw. I talked about exploiting a functor to lift any existing function so that it carries exception information with it, and how to compose functions of that kind by using a monad. In this third and last installment, we’re going to fully abandon checked exceptions and embrace the functional style of handling errors.

First, let’s examine what exceptions really are. During the evaluation of some expression (some function), unexpected conditions or data are encountered, with which it is undefined how to proceed. That is to say, for some inputs, the result of the computation is undefined. For example, when a parseInt function encounters a character that isn’t a digit (or a minus sign), what do we do? Well, we don’t know exactly, so we need some way to indicate failure. It would be invalid to return an integer. One could return null, but that isn’t exactly reliable, nor correct, and well, it would be lying since the type signature promises an integer.

So far, I’ve shown how we can use a Thrower monad to indicate that a computation can error. But the Thrower monad doesn’t do anything except wrap Java’s existing exception handling with a datastructure. And what do you think Java’s existing error handling is? It’s a monad. No, really, it is. In fact, Java is one big monad with bells on.

Note that throws changes the type of a method so that it may throw exceptions. Sound familiar? That’s what Thrower does (see part 1). Java’s throws keyword is the Kleisli arrow (see part 2) for Java’s exceptions functor. Binding is done with a combination of try and a Java keyword called “;” which I’m sure you use all the time without even batting an eye. You can then think of catch as a function that takes a monadic value and “extracts” from it, performing case analysis on the result.

Why did we need Thrower then? The difference is that throws needs to be hard-coded at method definition time, while our Kleisli arrow, which we called Partial, transforms function values “at runtime”.

Returning Errors

We now find that we can take this idea further. We don’t actually need the throws monad at all, and hence, we don’t need Thrower either. Don’t get me wrong. I like the Trower monad. I use the Thrower monad in production. But let’s explore what we can do to approach a more functional style of error handling, just for grins.

Instead of throwing Exceptions, we can just collapse error types into the return type. We’ll use a monad called Either, which looks very similar to Thrower except that errors are returned, not thrown. The Functional Java library luckily has Either already defined:

  public abstract class Either<A, B>

Either is the disjoint union of two types. A value of type Either<A, B> simply wraps a value of either type A or type B. The Either class comes with two static data constructors:

  public static <A, B> Either<A, B> left(final A a)

  public static <A, B> Either<A, B> right(final B b)

We’ll use the standard convention that left values represent failure, and that right values represent success.

Let’s see how we might use this data type for error handling. It’s really quite straightforward. The following declares the return type of parseInt to be either an Exception or an Integer (the left value can actually be any type, but… baby steps).

  public Either<Exception, Integer> parseInt(String s);

Oh, but wait. We’ve lost the laziness. Functional Java’s Either, by itself, is not lazy like Thrower is. If we do want laziness, we have to wrap the computation in a closure. For example, we can use fj.P1, which is just a generic interface with one method _1() which takes no arguments.

  public P1<Either<Exception, Integer>> parseInt(String s);

That’s better. Raising errors is done by returning a left value:

  return new P1<Either<Exception, Integer>>() {
    public Either<Exception, Integer> _1() {
      return Either.left(new Exception("You broke it!"));
    }
  };  

Sometimes you’re able to call functions that might fail, recovering with a default value:

  P1<Either<Exception, Integer>> a = parseInt(s);
  int addFive = (a._1().isLeft() ? 0 : a._1().right().value()) + 5;

Other times, you will be catching exceptions thrown by other people’s code and converting them to Either:

  public static P1<Either<Exception, Double>> divide(double x, double y) {
    return new P1<Either<Exception, Double>>() {
      public Either<Exception, Double> _1()
        try {
          return Either.right(x / y);
        } catch (Exception e) {
          return Either.left(e);
        }
      }
    };
  }

An error is sent to the caller simply by returning it. In the example below, the parse errors are explicitly caught and re-raised, while any errors raised by the divide method are implicitly returned.

  public static P1<Either<Exception, Double>> parseAndDivide(String sx, String sy) {
    final P1<Either<Exception, Integer>> x, y;
    x = parseInt(sx); y = parseInt(sy);
    return new P1<Either<Exception, Double>>() {
      public Either<Exception, Double> _1() {
        if (x.isLeft() || y.isLeft()) {
          return Either.left(x.isLeft() ? x.left().value() : y.left().value());
        }
        return divide(x.right().value(), y.right().value());
      }
    };
  }

Either is a monad, so we can lift existing functions into it, compose Eithers, sequence them, just like we did with Throwers. Here I’m taking an existing sine function and reusing it for values of type Either<Exception, Double>:

  F<Double, Double> sin = new F<Double, Double>() {
    public Double f(final Double a) {
      return Math.sin(a);
    };}

  P1<Either<Exception, Double>> z =
    divide(x, y).map(Either.rightMap_().f(sin));

If you need to work with more than one kind of error at a time, you can. Simply nest them on the right, like so: Either<E1, Either<E2, A>>. This is something we could not do with Thrower.

Nothing to Declare

Now, we’ve been returning Exceptions, but what does an Exception give you, really? You get some information about the failure, like an Exception type name, an error message, a stack trace, and possibly a nested Exception. If you know how to recover from an error, are you going to need the stack trace and the error message? No. You don’t actually have to return Exceptions to indicate errors if you don’t want to. You could just as well return String, Integer, fj.Unit, or your favourite data structure. Or you could return… Nothing.

There’s a simpler monad than Either which is often used in functional programming. It’s called Option (sometimes known as Maybe). An example is Functional Java’s fj.data.Option class, which I’ll demonstrate briefly here. Option<A> is a lot like a List<A> that can either be empty, or contain a single value of type A. For example:

  public static Option<Double> divide(double x, double y) {
    if (y == 0) {
      return Option.none();
    }
    return Option.some(x / y);
  }

This is similar to returning null on failure, except that callers won’t be surprised if the method fails to return a value. It’s declared in the method signature, after all. Option.none() has the correct type and will respond to methods declared on the Option class. If you want a lazy Option, simply wrap it in a P1 like we did with Either.

Not surprisingly, Option comes equipped with monadic methods like fmap (or simply “map”) to lift an F<A,B> to an F<Option<A>, Option<B>>, “bind” to chain Option-valued functions together, and “join” to collapse an Option<Option<A>> into an Option<A>. Option’s unit function is the static method Option.some. The instance method some() returns the value in the Option, if any. This last one is the Option equivalent to Thrower.extract().

So, now that we’re using Option and Either to indicate recoverable errors, what about unrecoverable errors? Those are the kinds of errors that we’re not going to catch, nor expect any reasonable application to catch. They should result in immediate and visible failure. For example, we might decide that it’s not reasonable to recover from a critical function if it returns nothing:

  Option<MyAppConfig> config = getAppConfig();
  if (config.isNone()) {
    throw new Error("No configuration!");
  } else {
    // Do stuff with config here.
  }

At this point, we have completely obviated Java’s checked exceptions mechanism. Recoverable errors are simply returned, and unrecoverable errors are thrown all the way out. We can now construct computations, and even if they might fail we can pass them around, compose them together, extract values from them, etc. All without a throws keyword in sight. The circle is complete.

That’s the end of Lazy Error Handling in Java. We’ve gone everywhere from throwing exceptions lazily, to higher-order chaining and manipulation of exception-throwing computations, to doing away with checked exceptions altogether. I hope you have found this short series educational and as fun to read as it was to write.

END