A Hitchhiker's Guide to the Functional Exception Handling in Java

Grzegorz Piwowarek @pivovarit

@pivovarit

Software Engineer | Trainer

commiter @ AssertJ, Vavr

blogger @ 4Comprehension

senior editor @ Baeldung

Exceptions:

Invisible in the source code
Create unexpected exit points
Behave like GOTOs
Easy to lose when async

"Every time you call a function that can raise an exception and don’t catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn’t think about."

October 13, 2003 by Joel Spolsky

Exceptions in Java are abused

Modeling absence
Modeling known business cases
Modeling alternate paths

    /**
     * Fills in the execution stack trace. This method records within this
     * {@code Throwable} object information about the current state of
     * the stack frames for the current thread.
     *
     * ...
     */
    public synchronized Throwable fillInStackTrace() {
       ...
    }

...and are not cheap.

http://normanmaurer.me/blog/2013/11/09/The-hidden-performance-costs-of-instantiating-Throwables/

-XX:-OmitStackTraceInFastThrow

https://www.javaspecialists.eu/archive/Issue187.html

Java Exceptions Antipatterns

Log and throw
Declaring that your method throws java.lang.Exception
Declaring that your method throws a large variety of exceptions
Catching java.lang.Exception
Destructive wrapping (throwing away stacks)
Log and return null
Catch and ignore
Throw within finally
Multi-line log messages
Unsupported operation returning null
Ignoring InterruptedException
Relying on getCause()

http://www.rockstarprogrammer.org/post/2007/jun/09/java-exception-antipatterns/

Error Handling in Go!

func foo(s string) (string, error) {
    // implementation
}

"Values can be programmed, and since errors are values, errors can be programmed. Errors are not like exceptions. There’s nothing special about them, whereas an unhandled exception can crash your program."

https://blog.golang.org/errors-are-values

response, err := foo("Dumbledore dies.")
if err != nil {
    // ...
}
// happy path like nothing happened

Error handling in Go does not disrupt the flow of control.

panic keyword

http://scrumreferencecard.com/scrum-reference-card/

Compile-time checks result in shorter feedback cycles

public class Person {
    private final String name;
    private final String surname;
    private final String address;
    private final String phoneNumber;
    private final String age;
}

Stringly-typed

public class Person {
    private final String name;
    private final Surname surname;
    private final Address address
    private final PhoneNumber phoneNumber;
    private final PositiveInteger age;
}

Strongly-typed

Optionality encapsulated

Person findOne(long id);

Optional<Person> findOne(long id);

sealed abstract class Try[+T]

final case class Success[+T](value: T) extends Try[T] { ... } 
final case class Failure[+T](exception: Throwable) extends Try[T] { ... }

Try in Scala

sealed -> all possible implementations were provided

public interface Try<T> { ... } 


final class Failure<T> implements Try<T> { ... }
final class Success<T> implements Try<T> { ... }

Try in Java(Vavr)

No sealed in Java (╯°□°）╯︵ ┻━┻)

static <T> Try<T> of(CheckedFunction0<? extends T> supplier) {
        Objects.requireNonNull(supplier, "supplier is null");
        try {
            return new Success<>(supplier.apply());
        } catch (Throwable t) {
            return new Failure<>(t);
        }
    }

Try in Java(Vavr) - instantiation

Try<U> map(Function<? super T, ? extends U> mapper)
Try<U> flatMap(Function<? super T, ? extends Try<? extends U>> mapper)
Try<T> filter(Predicate<? super T> predicate) ...

Try<T> orElse(Try<? extends T> other)

Try<T> onFailure(Consumer<? super Throwable> action)
Try<T> onSuccess(Consumer<? super T> action)

Try<T> recover(Class<X> exception, T value)

T get(); // do not use that.

Try API

List<URL> getSearchResults(String searchString) throws IOException

Try in Action I - consumer side

Try<List<URL>> getSearchResults(String searchString) { ... }

getSearchResults("javaday")
 .onFailure(ex -> LOG.info("Houston, we have a problem:" + ex.getMessage()))
 .getOrElse(() -> Collections.singletonList(javaday));

List<URL> getFromGoogle(String search) throws NoSuchElementException, IOException

Try in Action II - producer side

List<URL> getFromDuckDuckGo(String search) throws IOException

static Try<List<URL>> getSearchResults(String searchString) {
    return Try.of(() -> getFromGoogle(searchString))
      .recover(NoSuchElementException.class, emptyList())
      .recover(NSAForbiddenException.class, emptyList())
      .orElse(() -> Try.of(() -> getFromDuckDuckGo(searchString)));
}

static Try<URL> getSingleSearchResults(String searchString)

Try in Action III - flatmap

 getSingleSearchResults("javaday")
  .map(url -> url.openStream()) //Unhandled exception

 Try<Try<InputStream>> javaday = getSingleSearchResults("javaday")
  .map(url -> Try.of(url::openStream));


 Try<InputStream> javaday = getSingleSearchResults("javaday")
  .flatMap(url -> Try.of(url::openStream))

Try in Action IV - pattern matching

Try<InputStream> javaday = getSingleSearchResults("javaday")
  .flatMap(url -> Try.of(url::openStream))



Match(javaday).of(
  Case($Success($()), "Opened successfully"),
  Case($Failure($()), "Failed :(")
);

Tuple2<Person, ErrorObject> findOne(long id);


Tuple2<Person, ErrorObject> res = findOne(42);
if (res._2 != null) { ... }
if (res._1 != null) { ... }

Omnipresent "Java" feel instead

Simulating Go's feel with Tuple

Tuples are expected to hold non-nullable values

sealed abstract class Either[+A, +B]


final case class Left[+A, +B](value: A) extends Either[A, B]
final case class Right[+A, +B](value: B) extends Either[A, B]

Either in Scala

Disjoint union
Try<T> is isomorphic to Either<Throwable, T>
By convention, Right is success and Left is failure
In Scala, Either is right-biased now*

interface Either<L, R> 


final class Left<L, R> implements Either<L, R>
final class Right<L, R> implements Either<L, R>

Either in Java(Vavr)

Either.left("42");
Either.right(42);

Either instantiation

Separate factory methods for Left and Right:

LeftProjection<L, R> left()
RightProjection<L, R> right()

Either<X, Y> bimap(Function<..., X> leftMapper, Function<..., Y> rightMapper)

U fold(Function<..., U> leftMapper, Function<..., U> rightMapper)

R getOrElseGet(Function<? super L, ? extends R> other)

Either<R, L> swap()

L getLeft()  // do not use that unless you know what you are doing
L getRight() // yup, you guessed it.

Either API

case class FetchError(msg: String, response: HttpResponse)

Either in action - error object

public static class FetchError {
        private final String msg;
        private final HttpResponse response;

        public FetchError(String msg, HttpResponse response) {
            this.msg = msg;
            this.response = response;
        }

        public String getMsg() {
            return msg;
        }

        public HttpResponse getResponse() {
            return response;
        }

        @Override
        public String toString() {
            return "FetchError{" +
              "msg='" + msg + '\'' +
              ", response=" + response +
              '}';
        }

        @Override
        public boolean equals(Object o) {
            if (this == o) return true;
            if (o == null || getClass() != o.getClass()) return false;

            FetchError that = (FetchError) o;

            if (msg != null ? !msg.equals(that.msg) : that.msg != null) return false;
            return response != null ? response.equals(that.response) : that.response == null;
        }

        @Override
        public int hashCode() {
            int result = msg != null ? msg.hashCode() : 0;
            result = 31 * result + (response != null ? response.hashCode() : 0);
            return result;
        }
    }

Either in action - error object Java

Try<List<URL>> getSearchResults(String searchString)

Either<FetchError, List<URL>> getSearchResults(String searchString)

 getSearchResults("touk")
  .right()
  .filter(...)
  .map(...)
  .getOrElse(Collections::emptyList);


getSearchResults("touk")
  .left()
  .map(FetchError::getMsg)
  .forEach(System.out::println);

Either in action

public static Either<DnsUrl, URL> resolve(String url)

Modeling alternative paths

/** Returns either the next step of the tailcalling computation,
 * or the result if there are no more steps. */
@annotation.tailrec final def resume: Either[() => TailRec[A], A] = this match {
    case Done(a) => Right(a)
    case Call(k) => Left(k)
    case Cont(a, f) => a match {
      case Done(v) => f(v).resume
      case Call(k) => Left(() => k().flatMap(f))
      case Cont(b, g) => b.flatMap(x => g(x) flatMap f).resume
    }
}

Modeling alternative paths - Scala TailCalls

Absence modeling

Do we really need exceptions here?

Person findOne(long id) throws NoSuchElementException;
Integer valueOf(String s) throws NumberFormatException;

Optional<Person> findOne(long id);
Optional<Integer> valueOf(String s);

Why not?

Absence modeling

What if your language does not support that?

Switch language.
Build it yourself.
Use vavr.io (formerly known as Javaslang)
Take part in Java Community Process

Key Takeaways

Exceptions work best when you do not expect people to recover from them
Try can be used for representing computations that may throw an exception
Absence can be modelled with Option
Either can be used for advanced scenarios involving error objects and modeling alternative paths
VAVR is the new Guava

"To Try or not to Try, there is no throws"

A Hitchhiker's Guide to the Functional Exception Handling in Java

Grzegorz Piwowarek @pivovarit

@pivovarit

Exceptions:

Exceptions in Java are abused

...and are not cheap.

Java Exceptions Antipatterns

Error Handling in Go!

"To Try or not to Try, there is no throws"

Thank You!

Yoda, ~41:3

Grzegorz Piwowarek @pivovarit

References:

Functional Error Handling Raúl Raja Martínez

The Neophyte's Guide to Scala Daniel Westheide

A Hitchhiker's Guide to the Functional Exception Handling in Java

A Hitchhiker's Guide to the Functional Exception Handling in Java

Grzegorz Piwowarek

A Hitchhiker's Guide to the Functional Exception Handling in Java

Grzegorz Piwowarek @pivovarit

@pivovarit

Exceptions:

Exceptions in Java are abused

...and are not cheap.

Java Exceptions Antipatterns

Error Handling in Go!

"To Try or not to Try, there is no throws"

Thank You!

Yoda, ~41:3

Grzegorz Piwowarek @pivovarit

References:

Functional Error Handling Raúl Raja Martínez​

The Neophyte's Guide to Scala Daniel Westheide

A Hitchhiker's Guide to the Functional Exception Handling in Java

More from Grzegorz Piwowarek

Functional Error Handling Raúl Raja Martínez