Using Monads for Elegant Error Handling
summary
Argues that replacing rescue-and-nil patterns with a dry-monads result type (concrete Success/Failure values) makes error flow explicit, keeps exceptions for later logging (Airbrake/New Relic), and composes via a fmap/or pipeline so Faraday/Rails API calls propagate failures without hidden nils. Shows exact code: wrapping responses, using value! only after success, chaining fmaps, and or for error handlers. Notes costs: more boilerplate, an extra gem, and a steeper team learning curve.
AI-written summary · about
chapters (7)
- 0:00Start
- 9:57Consistent interface
- 10:17Refactor to Monads
- 14:33Convert to pipeline
- 15:45Handle failure with or
- 19:52Turn it up to eleven!
- 23:18Quiz
related talks
25mError handling with Monads in Ruby
43mMonads: Exploring Railway Oriented Programming in Ruby
30mRefactoring Ruby with Monads
30mRuby on Fails: effective error handling with...
30mDucks and monads: wonders of Ruby types
22mYou and your type[s] aren't welcome here
17mA closer look into error handling techniques
42mTaking inspiration from the functional world