TYPE-SAFE ERROR HANDLING IN THE AGE OF DOTTY
summary
Claim: using Dotty union types on the left side of Either lets methods declare exact, unrelated error sets (e.g. NoPotatoes | BurntFries) and preserves exhaustive checking at compile time while erasing to a common supertype at runtime. Implementation detail: Either needs a left-type hint but EitherT flatMap tweak or introducing an ErrorMonad/ErrorApplicative typeclass (F with two type args) makes inference work across transformers. Prototype compiles under Dotty, supports validations, and keeps runtime performance unchanged.
AI-written summary · about
chapters (14)
- 0:00Start
- 2:14Combining error types is messy
- 4:25Combining error types using an ADT
- 6:24Java Checked Exceptions
- 11:52Errors as union types
- 12:36Error unions vs checked exceptions Compare
- 13:07Handling errors
- 14:54What about type inference?
- 18:07Error Monad type class Represents dependent composition with errors
- 19:21Validations
- 19:55Error type classes hierarchy
- 20:58Type classes in Dotty with extension methods
- 22:36Our prototype for Error Monad
- 22:59Conclusion
