error-handling

Design and review error handling for TypeScript APIs and React clients.

Updated Jun 15, 2026
One-click install
npx skills add https://github.com/ravenslight2010/Production-run-calculator --skill error-handling-ravenslight2010
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: error-handling
Source: https://github.com/ravenslight2010/Production-run-calculator/tree/main/.agents/skills/error-handling
Command: npx skills add https://github.com/ravenslight2010/Production-run-calculator --skill error-handling-ravenslight2010

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Inconsistent error handling across an API and its client leads to swallowed exceptions, leaked internals, silent fallbacks, and confusing user-facing failures. This Skill provides a single set of rules and a review checklist so every failure path in the project's TypeScript API and React client is explicit, safe, and consistent with the existing contract. ## Core Features & Use Cases - API error contract enforcement: Maps known failures to deliberate HTTP statuses, routes unexpected errors to terminal JSON error middleware, and keeps the top-level { "error": "..." } envelope consistent with OpenAPI and generated clients. - Client failure handling: Treats every non-2xx response as failure, validates response shapes before adopting them into state, and preserves local/offline data when acknowledgments are missing. - Retry and timeout policy: Restricts retries to transient idempotent operations, bounds attempts with backoff and jitter, honors Retry-After, and requires explicit timeouts with consistent cancellation. - Use Case: When adding a new Express route that calls an external provider, use this Skill to ensure validation happens before provider work, errors map to safe JSON messages, logs exclude sensitive payloads, and the React client shows an actionable retry message. ## Quick Start Ask the AI to review the error handling of a specific API route or React data-fetching flow against this project's error-handling rules and checklist.

Frequently Asked Questions about error-handling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I handle API errors in an Express TypeScript server?

Validate request inputs before any database or provider work, map known failures to deliberate HTTP statuses, and let unexpected errors reach the terminal JSON error middleware. Return a top-level error envelope with a caller-safe message and never expose stack traces or SQL errors.

How should a React client handle non-OK fetch responses?

Treat every non-2xx response as a failure unless the endpoint contract says otherwise, and validate the body shape before adopting it into cache or state. Show users a concise action such as retry, correct input, or sign in without leaking internal details.

When should I retry a failed API request?

Retry only transient and idempotent operations, or mutations protected by a stable idempotency key. Never retry validation, authentication, authorization, or conflict failures, and bound attempts with exponential backoff and jitter.

What should API error responses never include?

Error responses must never include stack traces, SQL errors, filesystem paths, secrets, raw provider payloads, or sensitive request content. Logs should contain only bounded operational context like correlation IDs, timing, and safe identifiers.

Do React error boundaries replace async error handling?

No. Rendering error boundaries handle render failures only and do not replace event, request, mutation, or asynchronous error handling. Each async failure path needs its own explicit handling, rejection, and user-facing recovery action.