error-handling

Implement consistent API error handling with Korean messages and server-side logging.

Updated Dec 15, 2025

Search Tags:#API #logging #validation #server #error-handling #client

Ready to run

npx skills add https://github.com/jhlee0409/sidedish --skill error-handling-jhlee0409

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: error-handling
Source: https://github.com/jhlee0409/sidedish/tree/main/.claude/skills/error-handling
Command: npx skills add https://github.com/jhlee0409/sidedish --skill error-handling-jhlee0409

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

일관된 API 에러 응답과 예외 처리 패턴을 통해 서버와 클라이언트의 에러 처리를 단순화합니다. 에러 메시지는 한글로 제공되며 로깅은 서버에만 남깁니다.

Core Features & Use Cases

일관된 상태 코드와 메시지: 400/401/403/404/429/500 등 표준화된 응답.
클라이언트-사이드 ApiError 클래스: 클라이언트에서 타입 안전한 오류 다루기.
서버-사이드 로깅 및 예외 처리 패턴: try/catch, 로그, 재시도 전략 예시.

Quick Start

기존 API 경로를 리팩토링하여 잘못된 입력에 대해 한국어 상세 메시지와 함께 적절한 상태 코드를 반환하도록 구성합니다.

Frequently Asked Questions about error-handling

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

FAQPage Schema

How do I implement consistent error handling across API endpoints and client components?▼

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.

What's the best way to handle API errors on the client side with type safety?▼

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.

How do I set up server-side logging and error patterns for APIs?▼

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.

Can I use this error handling pattern with validation and retry strategies?▼

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.

What validation errors should I return from API endpoints?▼

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.

Do I need separate error handling for different API status codes?▼

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.