The design of error
summary
Argues that errors should be treated as designed signals rather than rare bugs, categorizing them as semantic, logic, or runtime issues and comparing handling patterns such as return values, exceptions, and errors-as-data. Explains how distributed systems can convert individual failures into opaque 500 responses unless traces and context travel with the error, and recommends design choices like circuit breakers, including meaningful business context in error payloads, and designing recoverable cases as auto-correcting UX.
AI-written summary · about
chapters (22)
- 0:00Beginning
- 0:35What is an error?
- 2:05Examples of errors
- 3:40What is an error?
- 4:55How to manage your errors?
- 10:11How to manage errors?
- 12:41Remove implicit errors
- 13:49Interact with operations
- 15:45The context
- 17:17Provide feedback
- 18:12Operations
- 20:59Payment
- 22:03Errors for users
- 23:45How to redefine an error?
- 27:58The real problem with errors
- 30:34Another way to handle errors
- 32:44Improve error handling
- 34:06The place of error in design
- 36:34The hidden error
- 38:10Eat our errors
- 39:18Errors have value
- 42:25Change your mindset
related talks
43mLearning to Live with Errors
20mThinking About Error Architecture Design
11mHow expert programmers think about errors
17mA closer look into error handling techniques
32mWriting Better Errors
44mA Practical Approach to Error Handling
44mA Practical Approach to Error Handling
34mHow to Teach a Service to Report Errors So They're Clear to Users and Machines