Exception design - the art of making debugging more accurate
summary
Exceptions are often ignored so design aims to make debugging immediate: throw for rare, business‑critical failures and use result objects for expected bad records; distinguish client vs server errors with HTTP status codes and capture response bodies (example: document signing service with Guzzle). Name exceptions by CPSR naming (Context Problem Solution [Reason]) instead of generic suffixes, group via namespaces, create factories or static makers for complexity, and preserve root causes with exception chaining and hierarchy so handlers can filter and diagnostics show the true source.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 0:29About me
- 1:03Why exceptions
- 2:15Introducing the speaker
- 2:59The problem
- 5:36Critical factors
- 11:59Two opinions
- 13:11Probability of the problem
- 20:01Not too verbose
- 21:03Context problem solution
- 21:44Examples
- 23:37Why
- 25:30Example
- 25:59Other things to remember
- 27:14Summary
related talks
35mHandling Exceptional Conditions with Grace and Elegance
51mLeveraging Typed Exceptions for Cleaner Error Handling
42mLeveraging Typed Exceptions for Cleaner Error Handling
30mThe World of Laravel Exceptions
51mExceptions in PHP: more complicated than it appears
17mA closer look into error handling techniques
32mComparative Error Handling...
40mManeuvering Errors within the Bowels of JavaScript