A Hitchhiker's Guide to the Functional Exception Handling in Java
Grzegorz Piwowarek @pivovarit
@pivovarit
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3938690/15039638_10209760884331013_529718478387824441_o.jpg)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3938695/800x600.png)
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/
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3948494/benchmark_throwable.png)
-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."
response, err := foo("Dumbledore dies.")
if err != nil {
// ...
}
// happy path like nothing happened
Error handling in Go does not disrupt the flow of control.
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3948561/d4a.gif)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3948577/6c2.gif)
panic keyword
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3943991/deus-vult-hello-sir-do-you-have-a-moment-to-talk-about-our-lord-and-savior-static-typing.jpg)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3952069/javascript-beyond-jquery-jfokus-2013-10-638.jpg)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3938725/dynamic-languafges-godfather.jpg)
http://scrumreferencecard.com/scrum-reference-card/
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3952098/scrum-iteration-detail.png)
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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3955124/vE1YouDB_400x400.png)
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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3956608/Screen_Shot_2017-06-30_at_19.32.57.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3956640/Screen_Shot_2017-06-30_at_19.57.22.png)
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"
Thank You!
![](https://s3.amazonaws.com/media-p.slid.es/uploads/531435/images/3850336/Yoda_SWSB__1_.png)
Yoda, ~41:3
Grzegorz Piwowarek @pivovarit
References:
Functional Error Handling Raúl Raja Martínez
The Neophyte's Guide to Scala Daniel Westheide