Functional Error Handling in Scala

Long Cao

Software Engineer @ MediaMath

What is error handling?

  • In Java, usually means exceptions and try/catch
  • Java has checked exceptions - compiler forces handling (pretty flawed, though)
  • Scala has only unchecked exceptions - compiler won't complain about it
class Coffee

def buyCoffee(money: Int): Coffee = {
  if (money < 3)
    throw new Exception(s"not enough money, need 3 dollars")
  else 
    new Coffee
}

What is functional error handling?

  • In Scala, that means using error handling types and passing in functions into their contexts
  • Referential transparency - replace expression with its value predictably​
    • Correctness and easier to understand quickly
    • Bonuses - compiler optimizations, memoization
class Coffee

// Not referentially transparent:
// Does this function always return a Coffee if it throws an exception?
def buyCoffee(money: Int): Coffee

What I hope you get out of this

  • Use error handling types to wrap over program flow: compiler guarantees
  • Don't throw exceptions, breaks referential transparency
  • If it flatMaps, "business logic" becomes functions that operate on your error handling monads - very testable, especially if stateless and pure
  • A practical application of functional error handling- you don't have to dive too far into the deep end or read/write byzantine code to reap the benefits

A vastly oversimplified explanation of 'monad'

  • A 'container' type that has predefined behavior
  • Allows for building computations - chain and compose of functions
  • It's a box!

http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html

So... how do we go about making it better?

How to improve using Option

  • Use Options to indicate found/not found states instead of throwing exceptions
    • Q: Do the types tell you anything about why it failed?
def buyCoffee(money: Int): Option[Coffee] = {
  if (money < 3)
    None
  else 
    Some(new Coffee)
}

scala> buyCoffee(2).flatMap(_ => Some("i got a coffee"))
res0: Option[String] = None

scala> buyCoffee(3).flatMap(_ => Some("i got a coffee"))
res2: Option[String] = Some(i got a coffee)

How to improve using Try

  • Represents success or failure states
  • Useful for mingling with/wrapping over exception-throwing code
import scala.util.{ Failure, Success, Try }

def buyCoffee(money: Int): Try[Coffee] = {
  Try {
    if (money < 3)
      throw new Exception(s"not enough money, need 3 dollars")
    else 
      new Coffee
  }
}

scala> buyCoffee(2)
res0: scala.util.Try[Coffee] = 
    Failure(java.lang.Exception: not enough money, need 3 dollars)

scala> buyCoffee(3)
res1: scala.util.Try[Coffee] = Success(Coffee@5e7cd6cc)

How to improve using Either

  • Disjoint union - return one of two wrapped types
    • By convention: right-biased, Left indicates error, Right: success
    • Can't flatMap over it out-of-the-box: not a monad
case class FailureReason(reason: String)

def buyCoffee(money: Int): Either[FailureReason, Coffee] = {
  if (money < 3)
    Left(FailureReason(s"not enough money, need 3 dollars"))
  else 
    Right(new Coffee)
}

scala> buyCoffee(2)
res0: scala.util.Either[FailureReason,Coffee] =
    Left(FailureReason(not enough money, need 3))

scala> buyCoffee(3)
res1: scala.util.Either[FailureReason,Coffee] =
    Right(Coffee@2a8448fa)

Library Alternatives

  • Disjoint Unions (similar to Either)
    • scalaz.\/
      • Right-biased disjunction
    • org.scalactic.Or
      • Left-biased
      • Reads as the "Good value Or Bad value"
    • cats.data.Xor
      • Right-biased disjunction

Common motif: Fail-fast error handling

  • Return the first error encountered in the flow when flatmapping over it
  • Kind of like an unhandled exception except the compiler will complain if you don't handle your cases
  • Most of these container types mentioned can be weaved together with for-comprehensions - will still fail fast!

For-comprehension with Or

import org.scalactic.{ Bad, Good, Or }

object CoffeeServiceOr {
  def purchaseCoffee(money: Int): Coffee Or FailureReason =
    for {
      beans <- buyBeans(money)
      coffee <- brewCoffee(beans)
    } yield coffee

  // fails without enough money
  def buyBeans(money: Int): Beans Or FailureReason = { ... }

  // fails 25% of the time to simulate a faulty grinder
  def brewCoffee(beans: Beans): Coffee Or FailureReason = { ... }
}

scala> CoffeeServiceOr.purchaseCoffee(2)
res0: org.scalactic.Or[Coffee,FailureReason] = 
    Bad(FailureReason(Not enough money to buy beans for a coffee, need 3))

scala> CoffeeServiceOr.purchaseCoffee(3)
res1: org.scalactic.Or[Coffee,FailureReason] = 
    Bad(FailureReason(Faulty grinder failed to grind beans!))

Caveats; things to think about

  • Mind your boundaries
    • Push final decision making with errors to the edges of your code
    • Be mindful of APIs exposed to clients - not everyone would know what to do with a scalaz.\/
  • Hard dependencies - scalaz, scalactic, & cats - be careful if your team isn't ready
  • Performance hits possible - lots of allocations, but measure before you conclude

Suggested Reading

  • Functional Programming in Scala - Chapter 4: "Handling errors without exceptions"

Questions?

Made with Slides.com