Error Handling in Scala with FP

Handling errors in Scala with the power of FP library.

Transcript

1. Error Handling in Scala with FP @jooohn1234
2. M3, Inc. @jooohn1234 • Call me “John”. • We no longer live in Hashimoto. • We’re going to release our very first stable baby in November.
3. 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
4. Error Representation
5. 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.
6. Error Representation in Scala Type System
7. Option • None or Some • Useful for handling absence. • No error detail. • No NullPointerException.
8. 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.
9. 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.
10. Either
11. 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.
12. Validated (Cats) / Validation (ScalaZ)
13. Validated (Cats) / Validation (ScalaZ)
14. 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
15. Error Handling Tips
16. 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.
17. Fail Fast
18. Avoid taking contextual value as an input • Handle errors in one place, and pass unwrapped values to another method. • More readable and reusable. BAD
19. Avoid taking contextual value as an input GOOD
20. 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.
21. 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.
22. Asynchronous Error Handling • Error Representation is used with Future in many cases. • Those error handlings tend to be redundant.
23. 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.
24. 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