IO monad & Error management: From Exceptions to Cats MTL
summary
Advocates replacing business exceptions with domain ADTs and keeping throwables for fatal technical failures, then encoding business failure as an Either inside IO and composing via EitherT so programs short circuit and still run as IO. Demonstrates monad transformers let small programs compose into one for-comprehension, and shows Cats MTL (typeclass abstractions + instances for transformers) removes much boilerplate and inference pain. Example code compiles and runs; caveats: transformer overhead and harder type inference motivate limiting exposure and using Cats MTL for nested stacks.
AI-written summary · about
chapters (18)
- 0:00Intro
- 3:33Why do we need 10 anyway?
- 5:38When things go wrong
- 6:32Use case: Modeling an authentication flow
- 9:57The issues with Exception
- 12:36This is a lie
- 13:53Domain errors are not exceptions
- 16:44Modeling errors using an ADT
- 23:05Rewriting our authentication method
- 25:43Look how far we've come!
- 27:37Challenges yet to address
- 28:46Can you guess what this code does ?
- 30:36The idea of Cats MTL
- 31:51How would one encode the effect of raising errors
- 32:40What about recovering ?
- 33:15We still get a dedicate channel for technical failures
- 34:16Implementing the authenticate method
- 35:47Interpreting the program
related talks
26mUP YOUR MTL GAME WITH CLASSY OPTICS
47mMonad transformers down to earth
24mUsing Monad Transformers without understanding them
01h 07mMonad transformers are good, actually
46mOptimusPrimeT
42mMonads you already use without knowing it
38mA roadtrip with monads: from MTL, through tagless, to BIO
59mDo or don’t There’s no try Or is there The power of monads explained Sort of