Error Handling

Production error handling has several layers: validation errors, network failures, API errors, rendering errors, authentication failures, and unexpected application errors. Each should have an appropriate recovery path.

Error categories

Centralized API handling

try {
  const data = await api.get("/orders");
  return data;
} catch (error) {
  const status = error.response?.status;

  if (status === 401) {
    throw new AuthenticationError();
  }

  if (status === 403) {
    throw new AuthorizationError();
  }

  throw new ApiError("Request failed");
}

User-friendly error model

{
  code: "ORDER_NOT_FOUND",
  message: "The order could not be found.",
  correlationId: "REQ-10045"
}

Retry design

Retries should be limited. Network failures and transient 5xx failures may be retry candidates. Validation and permission failures normally should not be retried automatically.

Global error strategy

flowchart TD
A[Error occurs] --> B{Category}
B --> C[Validation]
B --> D[API]
B --> E[Authentication]
B --> F[Authorization]
B --> G[Render]
C --> H[Field message]
D --> I[API error UI]
E --> J[Login]
F --> K[Forbidden]
G --> L[Error Boundary]

Output

Validation:
Email is required

Network:
You appear to be offline.
[Retry]

401:
Your session expired.
[Sign in]

500:
Something went wrong.
Reference: REQ-10045

Common mistakes

• Catching errors and silently ignoring them.
• Showing technical errors to users.
• Retrying all failures.
• Logging sensitive tokens or personal data.
• Using one generic error component for every situation.

Interview questions

• How do you design error handling in React?
• How do API errors differ from rendering errors?
• Which errors should be retried?
• How do you avoid exposing sensitive information?