Error Handling in Scala

Yuvi Masory - @ymasory

Scala for Startups

January 29, 2013

Slides live at http://yuvimasory.com/talks.

Section A:
Basic exception handling

Since Scala's try/catch blocks use pattern matching, this section is just a review of what patterns are available to you.

Consider this function

import scala.io.Source

def readFile(path: String) =
  (Source fromFile path).mkString()

A1. Catch an exception

import java.io.IOException

try {
  readFile("/opt/data")
}
catch {
  case e: IOException =>
}
  

A2. Catching multiple types

import java.lang.NumberFormatException

try {
  readFile("/opt/social-security").toInt
}
catch {
  case e @ (_: IOException | _: NumberFormatException) =>
}
  

A3. Subtyping exceptions

import java.nio.file.{ Files, FileSystemException,
                       FileSystems }

try {
  val path = FileSystems.getDefault getPath "/opt/data"
  Files readAllBytes path
}
catch {
  // abstracting over:
  //   - java.nio.file.NoSuchFileExceptions
  //   - java.nio.file.NotDirectoryException
  //   - all other subclasses
  case e: FileSystemException =>
}
  

A4. Catching exceptions by message

try {
  readFile("/opt/data").toInt
}
catch {
  case e: IOException
    if e.getMessage contains "Is a directory" =>
  case e: IOException =>
}
  

A5. Catching all exceptions

try {
  readFile("/opt/data").toInt
}
catch {
  case e: Exception =>
}
  

A6. DON'T DO THIS

try {
  readFile("/opt/data").toInt
}
catch {
  // this will match scala.util.control.ControlThrowable
  case _ =>
}
  

A7. Catching "everything"

try {
  readFile("/opt/data").toInt
}
catch {
  case t: ControlThrowable => throw t
  case _                   =>
}
  

Section B:
What's wrong with exceptions?

Referential transparency

• Is there a value the RHS of this assignment can be replaced with?

          val a1: Nothing = sys error "foo"
        

• No.

  See Functional Programming in Scala, chapter 4.

Should I throw an exception?

Three possible answers

• Answer 1: No.

• Answer 2: If you're going to catch it, no.

• Answer 3: If you're going to catch it anywhere except the top-level "loop" of your application (E.g., Scalatra route handler, Play action, or Swing event loop), no.

Section C:
Value-oriented exception handling

import scala.util.control._

• When should you use these patterns over those in Section A?

  ALWAYS!

• Since this is a regular libary, operating on standard values and types, the opportunities for extension and customization are endless.

• Read this! Abstracting exception handlers in Scala

Try[A] (slightly simplified)

sealed trait Try[A]

case class Failure[A](e: Throwable) extends Try[A]

case class Success[A](value: A)     extends Try[A]
  

C1. try/catch sans boilerplate

    import scala.util.Try

    def tryReadFile(path: String): Try[String] = Try {
      (Source fromFile path).mkString()
    }
  

C2. Matching on Try

    import scala.util.control._
    import scala.util.control.Exception._

    tryReadFile("/opt/data") match {
      case Success(value) =>
      case Failure(e)     =>
    }
  

Catch[A]

    val c: Catch[A] = catching(classOf[IOException])
  

C3. Converting to Option

    val sOpt: Option[String] =
      catching(classOf[IOException]).opt {
        readFile("/opt/data")
      }
  

C3. Converting to Option, cont ...

    val sOpt: Option[String] =
      failing(classOf[IOException]) {
        readFile("/opt/data")
      }
  

C4. Converting to Either

    val eith: Either[Throwable, String] =
      catching(classOf[IOException]).either {
        readFile("/opt/data")
      }
  

C5. Side-effecting

    val unit: Unit =
      ignoring(classOf[IOException], classOf[NumberFormatException]) {
        println(readFile("/opt/social-security").toInt)
      }
  

C6. DON'T DO THIS

    allCatch {
      readFile("/opt/data")
    }
  

C7. Catching "nonfatal" errors

    nonFatal {
      readFile("/opt/data")
    }
  

Which errors are "fatal"?

• VirtualMachineError (includes OutOfMemoryError)
• ThreadDeath
• InterruptedException
• LinkageError
• ControlThrowable
• NotImplementedError

C7. Catching "nonfatal" errors, cont ...

    try {
      readFile("/opt/data")
    } catch {
      case NonFatal(e) =>
    }
  

C8. Provide a default value

    failAsValue(classOf[IOException])("") {
      readFile("/opt/data")
    }
  

C9. Custom error handling

(I'm still working on this one ...)

    def logError(t: Throwable): Int = {
      println("Error: " + t)
      -1
    }

    def loggingExceptions(block: => A) =
      catching(classOf[Exception]).withApply {
        logError _
      }.apply(block)
  

C10. What about finally?

• With catch logic

          catching(classOf[IOException]).andFinally {
            println("cleanup")
          }.apply { readFile("/opt/data") }
        

• No catch logic

          ultimately(println("cleanup")) {
            readFile("/opt/data")
          }
        

Parting thoughts on scala.util.control

• There's a lot more you can do with this package. I'm still digging into it.

• You can do all the usual for-comprehension monadic coolness with Try, just like with Option, Either, Validation, etc.

Section D:
Option[A]

Option[A] (slightly simplified)

sealed trait Option[A]

case class Some[A](a: A) extends Option[A]

case object None         extends Option[Nothing]
  

D1. Matching on Option

(Option[A], Option[A] => B) => B

    val iOpt: Option[Int] = //...

    val sOpt: Option[String] = iOpt match {
      case Some(value) => value.toString
      case None        => ""
    }
  

Stop matching on Option!!

D2. Only consider Some

(Option[A], A => B)) => Option[B]

    val sOpt: Option[String] =
      iOpt map { value => value.toString }

    val sOpt: Option[String] =
      iOpt map { _.toString }
  

D3. More chances

(Option[A], Option[A]) => Option[A]

    def foo(i: Int): Option[String]

    val sOpt: Option[String] =
      foo(1).orElse {
        foo(2).orElse {
          foo(3).orElse {
            foo(4)
          }
        }
      }
  

D4. Consider both cases

(Option[A], B, A => B)) => B

    val sOpt: Option[String] =
      iOpt.fold("") { _.toString }
  

D5. Provide default value

(Option[A], A) => A

    val i: Int = iOpt getOrElse 0
  

D6. Monads! (flatmap)

(Option[A], A => Option[B]) => Option[B]

    import scala.math.sqrt

    def perfectSqrt(i: Int): Option[Int] = {
      val root: Int = sqrt(i).toInt
      if (root * root == i) Some(root) else None
    }

    val i: Int = //...

    perfectSqrt(i).flatMap {
      perfectSqrt(_).flatMap {
        perfectSqrt(_)
      }
    }

  

D7. Monads! (for-comprehensions)

(Option[A], A => Option[B]) => Option[B]

    def triplePerfectSqrt(i: Int): Option[Int] = for {
      j <- perfectSqrt(i)
      k <- perfectSqrt(j)
      l <- perfectSqrt(k)
    } yield l
  

D8. Are you there?

Option[A] => Boolean

    val b1: Boolean = iOpt.isDefined

    val b2: Boolean = iOpt.isEmpty
  

D9. Are you there and ...?

(Option[A], A => Boolean) => Boolean

    val b1: Boolean = iOpt exists { _ > 0 }
  

D10. Dealing with null

A => Option[A]

    //MAY RETURN NULL
    def javaFunction(): String

    val sOpt: Option[String] = Option(javaFunction())
  

D11. Only execute if all the Options are defined

    val iOpt: Option[Int] = //...
    val cOpt: Option[Char] = //...
    val dOpt: Option[Double] = //...

    val sOpt: Option[String] = for {
      i <- iOpt
      c <- cOpt
      d <- dOpt
    } yield s"$i$s$d"
  

Section E:
Either[E, A]

Either[E, A] (slightly simplified)

sealed trait Either[E, A]

case class Left[E](e: E)  extends Either[E, A]

case class Right[A](a: A) extends Either[E, A]
  

E1: Pattern matching on Either

(Either[E, A], E => B, A => B) => B

    val eith: Either[Int, String] = //...

    eith match {
      case Left(e)      =>
      case Right(value) =>
    }
  

E2: Consider Left and Right both

(Either[E ,A], E => B, A => B) => B

    eith.fold(
      _.toString,
      _.reverse
    )
  

Where are all the Either methods?!

• Do higher order functions operate on the Left or Right case?

• Either isn't "right-based" or "left-based".

• You will work with left and right projections.

E3: Get the first failure, else proceed

    def div(i: Int, j: Int): Either[String, Int] =
      if (j != 0) Right(i / j)
      else Left(s"can't divide $i by 0!")

    val i, j, k, l, m, n = // ... integers

    for {
      i <- div(j, k).right
      l <- div(m, n).right
    } yield i + l
  

E3: Get the first success, or procceed

    for {
      i <- div(j, k).left
      l <- div(m, n).left
    } yield i + l
  

Homework

• Most of the Option patterns apply to the right and left Either projections.

• I'll leave browsing the Either.LeftProjection and Either.RightProjection scaladocs to you.

Section F:
Scalaz's Validation[E, A]

Validation[E, A] (slightly simplified)

sealed trait Validation[E, A]

case class Success[E, A](a: A) extends Validation[E, A]

case class Failure[E, A](e: E) extends Validation[E, A]
  

Some thoughts on Validation

• Validation[E, A] is very similar to Either[E, A]

• It's right-based.

• I won't repeat all the Either/Option patterns.

• Caution: syntax is in flux during the Scalaz 6 -> 7 rewrite.

• Also, Scalaz has some enhancements to Option & Either that are worth a look.

Accumulating errors

• Wouldn't it be nice if we could accumulate errors, instead of stopping on the first one?

• Read this! A Tale of 3 Night Clubs

ValidationNEL (slightly simplified)

case class NonEmptyList[A](head: A, tail: List[A])

type ValidationNEL[E, A] = Validation[NonEmptyList[E], A]
  

Consider this domain

class Person(
  age: Int, clothes: String,
  sober: Boolean, male: Boolean
)

def checkAge(p: Person): Validation[String, Person] =
  if (p.age < 18) Failure("too young!") else Success(p)

def checkClothes(p: Person): Validation[String, Person] =
  if (p.clothes contains "jeans") Failure("dress up!")
  else Success(p)

def checkSobriety(p: Person): Validation[String, Person] =
  if (p.sober) Success(p) else Failure("sober up!")
  

F1. Accumulate errors with applicative functors

def cost(p: Person): ValidationNEL[String, Int] = (
  checkAge(p).liftFailNel |@| 
  checkClothes(p).liftFailNel |@|
  checkSobriety(p).liftFailNel) {
    case (_, _, c) => if (c.male) 50 else 25
  }
 

Let's generalize

• Accumulating errors is pretty cool right?

• But what about a large (or unkown) number of checks?

Aside:
type lambdas
(aka job security)

Read this! What are type lambdas in Scala and what are their benefits?

Type systems

• Nominal types

          trait Duck {
            def quack(): Unit
          }
          def foo(d: Duck) =
        

• Structural types

          def foo(d: { def quack(): Unit }) =
        

• Duck "types" are structural types minus the static type system. (I.e., runtime checking of compatability.)

Example: Can Either[E, A] be a Monad?

See, no need to even know what a Monad is.

       trait Monad[M[_]]
     

Option is easy, since it only has one type parameter

       class OptionMonad[A] extends Monad[Option]
     

But what about Either? This won't compile.

       class EitherMonad[A] extends Monad[Either]
     

This won't compile either.

       class EitherMonad[A] extends Monad[Either[E]]
     

Partially applying types

• Can types be partially applied, like functions?

• It was never intended, but we can hack it with structural types!

• It's simple!

          //recall our definition of Monad
          trait Monad[M[_]]
  
          //solution
          class EitherMonad[A]
            extends Monad[({type λ[α] = Either[A, α]})#λ] 
        

Huh?

Let's build that one up step by step.

• structural type with no restrictions, equivalent to the nominal type AnyRef

          { }
        

• what do you know! the object defined by the structural type has a type alias of the type we're looking for!

          { type L[A] = Either[E, A] }
        

• reference the desired type directly

          { type L[A] = Either[E, A] }#L
        

• this looks vaguely like a lambda expression, so ...

          { type λ[α] = Either[E, α] }#λ
        

Once again.

• Our solution

         trait Monad[M[_]]
  
         class EitherMonad[A]
           extends Monad[({type λ[α] = Either[A, α]})#λ] 
       

• FYI: Type macros (part of Macro Paradise at present) will allow a nicer syntax. (But perhaps less job security.)

/Aside

F2. Accumulate errors with traverse

def cost(p : Person) : ValidationNEL[String, Int] = {
  val checks = List(
    checkAge _,
    checkClothes _,
    checkSobriety _
  )
  checks.traverse[({type λ[α] = ValidationNEL[String, α]})#λ, Person](
    _ andThen (_.liftFailNel) apply p
  ) map {
    case c :: _ => if (c.male) 50 else 25
  }
}
 

Section G:
Lift's Box[A]

Box[A] (slightly simplified)

sealed trait Box[A]

case class Full[A](a: A) extends Box[A]

abstract class EmptyBox  extends Box[Nothing]

case class Failure(
  msg: String, e: Box[Throwable], chain: Box[Failure]
) extends EmptyBox

case class Empty extends EmptyBox
  

Sorry!

• No time for Box.

• Take home message: Box isn't as principled as Validation/NEL + Try, but check it out for an alternative way to accumulate errors.

Phew!

The end.