Error Handling Patterns

When to Use

• Building API endpoints that must return consistent error responses
• Creating custom exception hierarchies for a domain model
• Implementing retry logic for unreliable network calls or external services
• Designing React error boundaries for component-level fault isolation
• Wrapping third-party libraries that throw unpredictable errors
• Converting between error representations at architectural boundaries (e.g., domain errors to HTTP errors)
• Adopting the Result pattern to avoid exceptions for expected failure paths

When NOT to Use

• Simple one-off scripts or throwaway prototypes where unhandled crashes are acceptable
• Configuration files, static data, or declarative markup with no runtime logic
• Pure data transformation functions where invalid input should be prevented by types, not caught at runtime