A closer look into error handling techniques
summary
Claim: errors belong in the return type and treating them as first-class responses makes handling and composition predictable. Compares try/catch anti-pattern to using sealed-result containers, functional types like Either/Arrow for composable mapping, and Kotlin's built-in Result which forces Throwables. Recommends sealed classes for small apps, Arrow for functional teams and libraries with senior developers, and Result for a pragmatic middle ground. Also stresses logging, modeling error payloads, and team-wide agreement on the chosen strategy.
AI-written summary · about
chapters (10)
- 0:00Introduction to error handling
- 1:09Why errors matter in development
- 2:57Problems with try-catch approach
- 5:27Errors as alternative use cases
- 6:50Monads and sealed classes
- 8:40Optional vs error handling
- 10:04Either data type explained
- 11:50Arrow and Kotlin Result
- 13:59Choosing the right strategy
- 15:45Team communication and logging
related talks
43mError Handling Strategies for Kotlin Programs
43mFunctional Error Handling
38mBeyond Exceptions: Building Resilient Android Apps with Safety-Critical Principles
44mInitiatory Journey from Exceptions to Composable Error Types
36mDart Exceptions: Best Practices
01h 01mModern C++ Error Handling
27mUsing Monads for Elegant Error Handling
45mThe design of error