error-handling

Consistent error handling uses standardized HTTP status codes (400, 401, 403, 404, 429, 500) with centralized error messages, server-side logging patterns, and a client-side ApiError class for type-safe exception handling across all layers.

Use a dedicated ApiError class to wrap API responses, enabling type-safe error handling in client components. This pattern provides consistent access to error codes and messages while integrating with UI patterns like toast notifications and retry logic.

Implement try/catch blocks in API endpoints with centralized logging that captures exceptions server-side only. Standardize response formats with appropriate HTTP status codes and error messages, enabling reliable diagnostics without exposing logs to clients.

Yes. The pattern enforces standard validation error responses (400) alongside retry-friendly status codes (429), supporting client-side retry logic and toast notifications for user-facing feedback across validation failures and transient errors.

Return 400 Bad Request with detailed validation error messages from a centralized dictionary. Include specific field-level validation failures so clients can display precise, actionable feedback to users.

Use a unified error handling framework with status-code-specific handling: 401 for authentication, 403 for authorization, 404 for resources, 429 for rate limits, and 500 for server errors—all returning consistent message structures.