Error And Edge-Case Design
Definition
Identify exceptional and uncommon situations, then choose simple semantics for each. Prefer defining errors and special cases out of existence when it reduces complexity without hiding important truth.
Questions To Ask
- What invalid input, stale state, permission failure, conflict, or external failure can happen?
- Which cases can the user correct?
- Which cases should be prevented by design?
- Which errors can be merged under one response?
- What should be logged, retried, or surfaced?
Existing Project Comparison
- Inspect existing error types, handlers, UI messages, database constraints, retries, logs, and tests.
- Flag inconsistent error shapes or duplicate edge-case logic.
- Avoid adding rare error branches that every caller must understand.
Suggestive Plan
- List errors by layer.
- Classify user-correctable, conflict, permission, external, and internal bug cases.
- Define response semantics and owner.
- Simplify or define away unnecessary cases.
- Add tests for important failures.
Example
If the request was confirmed while the editor was open, return a conflict response and show "This request is already confirmed; refresh to view the current appointment."
Vocabulary
- Edge case: uncommon but possible situation.
- Conflict: state changed so the requested action no longer applies.
- Define away: choose semantics that eliminate unnecessary failure handling.
- Error owner: module responsible for response and recovery.
Expected Outcome
Produce an error matrix covering cases, layer, user message, system response, owner, simplification option, and tests.
1---2name: error-and-edge-case-design3description: Design error handling and edge cases for one feature across frontend, API, backend, database, and tests. Use when deciding which failures to prevent, define away, recover from, or expose to users.4---56# Error And Edge-Case Design78## Definition910Identify exceptional and uncommon situations, then choose simple semantics for each. Prefer defining errors and special cases out of existence when it reduces complexity without hiding important truth.1112## Questions To Ask1314- What invalid input, stale state, permission failure, conflict, or external failure can happen?15- Which cases can the user correct?16- Which cases should be prevented by design?17- Which errors can be merged under one response?18- What should be logged, retried, or surfaced?1920## Existing Project Comparison2122- Inspect existing error types, handlers, UI messages, database constraints, retries, logs, and tests.23- Flag inconsistent error shapes or duplicate edge-case logic.24- Avoid adding rare error branches that every caller must understand.2526## Suggestive Plan27281. List errors by layer.292. Classify user-correctable, conflict, permission, external, and internal bug cases.303. Define response semantics and owner.314. Simplify or define away unnecessary cases.325. Add tests for important failures.3334## Example3536If the request was confirmed while the editor was open, return a conflict response and show "This request is already confirmed; refresh to view the current appointment."3738## Vocabulary3940- Edge case: uncommon but possible situation.41- Conflict: state changed so the requested action no longer applies.42- Define away: choose semantics that eliminate unnecessary failure handling.43- Error owner: module responsible for response and recovery.4445## Expected Outcome4647Produce an error matrix covering cases, layer, user message, system response, owner, simplification option, and tests.
harsh817