Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Error Handling in Scala with FP

Jun Tomioka
October 13, 2017

Error Handling in Scala with FP

Handling errors in Scala with the power of FP library.

Jun Tomioka

October 13, 2017

More Decks by Jun Tomioka

Other Decks in Technology


  1. M3, Inc. @jooohn1234 • Call me “John”. • We no

    longer live in Hashimoto. • We’re going to release our very first stable baby in November.
  2. Error Handling in Scala with FP 1. Error Representation a.

    Exception b. Option c. Try d. Either e. Validated, Validation 2. Error Handling Tips a. Fail fast b. Avoid taking contextual value as an input c. Either vs Validated d. Abstract away Error Representation e. Asynchronous Error Handling
  3. Exception • SHOULD BE AVOIDED. • Every exception is unchecked

    in Scala. ◦ Can’t benefit from Scala type system. ◦ Breaks referential transparency. • Get lost in async boundaries.
  4. Option • None or Some • Useful for handling absence.

    • No error detail. • No NullPointerException.
  5. Try • Failure or Success • Useful for handling Throwable

    in Scala. ◦ Exception should be avoided though… ◦ wrap the standard library or third party libraries which potentially throw exceptions. • Completion of Future / Promise is represented with Try.
  6. Either • Left or Right • Useful for handling any

    type of error representation. • Right represents the happy case and Left represents the error case by convention. • sealed trait is one of a good candidate for Left representation.
  7. Validated (Cats) / Validation (ScalaZ) • Invalid or Valid (Cats),

    Failure or Success (ScalaZ) ◦ Similar to Either, but represents parallel errors. ◦ I’ll compare this with Either later. • Collect all errors at once. • Often used with NEL (NonEmptyList). ◦ ValidatedNel / ValidationNel type alias is prepared.
  8. Error Representation in Scala Error Representation When to use Exception

    Should be avoided Option Modeling Absence Try Capturing Throwable Either Modeling Sequential Errors Validated / Validation (from FP library) Modeling Parallel Errors
  9. Fail Fast • Use flatMap in order to achieve Fail-Fast

    principle. • for comprehension is more readable in many cases. ◦ Scala’s “for comprehension” is not only for Monad, but works well with Monads like Option, Try, Either (right biassed). ◦ (For FP beginners) Think of Monad as classes with flatMap method. • When failure happens, it gives up subsequent computation.
  10. Avoid taking contextual value as an input • Handle errors

    in one place, and pass unwrapped values to another method. • More readable and reusable. BAD
  11. Either vs Validated Representation semantics for comprehension collect all errors

    Either sequential ◯ ☓ Validated (Cats) parallel ☓ (offers andThen for sequential validation) ◯ Validation (ScalaZ) parallel △ (offers separated FlatMap object) ◯ • Biased Either is Monad, so it works well with for comprehension. • Validated can be Monadic, but the behaviour is inconsistent with Applicative.
  12. Abstract away Error Representation • We can write generic “failable”

    method with MonadError / ApplicativeError • Useful for switch error representation in code base. • Be careful not to be TOO MUCH abstraction.
  13. Asynchronous Error Handling • Error Representation is used with Future

    in many cases. • Those error handlings tend to be redundant.
  14. Asynchronous Error Handling • Use MonadTransformer to handle sequential asynchronous

    error handling. ◦ MonadTransformer is a Monad combined with 2 higher kind types. ▪ Can be used in for comprehension.
  15. Recap Error Representation in Scala • Avoid Exception. • Use

    the most suitable representation for your purpose. Error Handling Tips • There’re some useful techinques for error handling. References: • https://typelevel.org/cats/ • https://speakerdeck.com/raulraja/functional-error-handling