Ruby on Fails: effective error handling with...
summary
Argues Rails apps need explicit, intentional error classes (inherit from StandardError, add data, e.g. ItemNotAvailable) and warns rescue_from Exception is dangerous and against using exceptions for normal flow control. Recommends a centralized error reporter via Rails’ subscriber (initializer + report(error, meta)), a module with report_error, using error.cause, layer-supertype errors (CheckoutServiceError → specific errors), as_json conventions, and containing monads/result objects inside use-case services.
AI-written summary · about
chapters (23)
- 0:00Effective error handling intro
- 1:02Ruby exceptions and errors
- 2:48Error handling anti-patterns
- 5:38Goals for error handling
- 6:20Intentional error design
- 7:24Discovering error scenarios
- 8:29Custom error classes
- 9:51Encapsulating errors
- 11:16Avoiding leaky abstractions
- 12:20Enriching error info
- 13:23Fraud detection errors
- 14:25Original errors with cause
- 15:08Polymorphism for errors
- 16:10Layer supertype errors
- 17:16Centralized error strategy
- 19:00Rails error reporter
- 20:25Centralized error reporting
- 21:50Rails error logging
- 23:17Rails error conventions
- 24:19Safe error defaults
- 25:44Breaking conventions
- 26:47Rails flow strategies
- 28:31Key takeaways
