error-handling-patterns

Error Handling Pattern: Skill Details

Skill Overview

Error Handling Patterns is a skill focused on building resilient applications. It covers core patterns such as exception handling, the Result type, error propagation, and graceful degradation. It helps developers make the right decisions when implementing error handling, designing APIs, or improving application reliability.

Applicable Scenarios

Implementing Error Handling for New Features

When developing new features, design a sensible error handling strategy, including catching exceptions, returning error information, and recovery mechanisms. This ensures the application handles exceptional situations gracefully instead of crashing.

Designing Reliable APIs

When building frontend or backend APIs, define a clear error response structure, error code conventions, and error message formats. This allows callers to accurately understand the cause of the error and take appropriate actions.

Troubleshooting Problems in Production

When errors occur in production, use structured error handling patterns to quickly identify the root cause. By improving error logs and trace information, you can shorten debugging time.

Core Capabilities

Multilingual Error Handling Patterns

Covers error handling mechanisms across mainstream programming languages, including exception-based patterns (Java, Python, C#), Result-type patterns (Rust, Go, Swift), and value-based error patterns. This helps developers choose the error handling approach best suited to the current project.

Error Propagation and Recovery Strategies

Provides methods for designing complete error propagation chains, including how to pass error context between different layers, when to wrap errors, when to let errors bubble up, and concrete implementations of recovery strategies such as retry mechanisms, the circuit breaker pattern, and graceful degradation.

Fault-Tolerant Design for Distributed Systems

Specifically targets error handling patterns for distributed systems and microservices architectures, including timeout handling, prevention of cascading failures, service degradation strategies, and cross-service error tracing. It helps build highly available distributed applications.

Common Questions

Which is better: Result type or exception handling?

The Result type is more suitable for expected errors (e.g., user input validation failures, resources not found). These errors are part of business logic and should be handled explicitly. Exceptions are more suitable for unexpected situations where the program cannot continue (e.g., network interruptions, database connection failures). The choice depends on language support and team coding conventions.

What information should an API error response include?

A good API error response should include:

A machine-readable error code (for program decisions)

A human-readable error message (for developers)

Context information about where the error occurred (e.g., request parameters, resource identifiers)

An optional link to documentation for help

Avoid exposing sensitive internal system details in error messages.

When should retry mechanisms be used?

Retry mechanisms are suitable for temporary failures, such as network glitches, services being temporarily unavailable, or resource lock contention. When using them, set a maximum retry count, a backoff strategy (e.g., exponential backoff), and criteria for which error types are retryable. For logic errors (e.g., insufficient permissions, data validation failures) or known persistent failures, do not retry—fail fast and notify the user.