スキル error-handling-patterns
📦

error-handling-patterns

安全

堅牢なエラーハンドリングパターンの実装

こちらからも入手できます: wshobson

Python、TypeScript、Rust、Goにおける例外、Result型、リトライロジック、サーキッドブレーカーなど、エラーハンドリングパターンをマスターすることで、より回復力のあるアプリケーションを構築します。

対応: Claude Codex Code(CC)
🥉 75 ブロンズ
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「error-handling-patterns」を使用しています。 外部APIを呼び出すときにエラー処理方法は？

期待される結果:

外部API呼び出しには、複数のレイヤーのエラーハンドリングを実装します：(1) 異なる障害タイプ用のカスタム例外階層、(2) 一時的なエラーのための指数バックオフ付きリトライ、(3) カスケード障害を防ぐためのサーキッドブレーカー、(4) フォールバックデータによるグレースフルデグラデーション。例：カスタム例外（NetworkError、TimeoutError、RateLimitError）を作成し、3回の試行と指数バックオフでAPI呼び出しをリトライデコレータでラップし、障害率をトラックするためにサーキッドブレーカーを使用し、APIが利用できない場合はキャッシュされたフォールバックを提供します。

「error-handling-patterns」を使用しています。 Result型はいつ例外の代わりに使用するべきですか？

期待される結果:

予期される障害（検証エラー、みつかりませんエラー、ビジネスロジックエラー）にはResult型を使用し、呼び出し元が成功と失敗の両方のケースを明示的に処理する必要があります。真正に例外的な状況（ヌルポインタ、メモリ不足、予期しないランタイムエラー）には例外を使用します。Result型はエラー処理を型システムで明示的にし、失敗ケースを考慮することを呼び出し側に強制します。TypeScriptでは、Result<T, E> = { ok: true, value: T } | { ok: false, error: E }です。Rustでは、?演算子とResult<T, E>型が組み込みサポートを提供します。このアプローチはコードの可読性を向上させ、予期しないランタイムエラーを減少させます。

セキュリティ監査

安全
v1 • 2/24/2026

This skill is a documentation and educational resource about error handling patterns. The static scanner flagged 49 potential issues, but after evaluation all findings are FALSE POSITIVES. The detected patterns (backtick syntax examples, HTTP library examples, error categories) are educational code snippets in markdown documentation, not executable malicious code. No security concerns identified.

2
スキャンされたファイル
674
解析された行数
0
検出結果
1
総監査数
セキュリティ問題は見つかりませんでした
監査者: claude

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
50
コミュニティ
100
セキュリティ
100
仕様準拠

作れるもの

アプリケーションの信頼性向上

適切な例外階層と意味のあるエラーメッセージを使用して、新規または既存の機能に堅牢なエラーハンドリングを追加します。

フォールトトレラントシステムの構築

分散システムとマイクロサービスのために、リトライロジック、サーキッドブレーカー、グレースフルデグラデーションを実装します。

クロス言語パターンの学習

各状況に最适合なアプローチを選択するために、Python、TypeScript、Rust、Goのエラーハンドリングアプローチを理解します。

これらのプロンプトを試す

基本的な例外処理 
データベースからユーザーデータを取得する関数の適切なエラーハンドリングを実装する手助けをしてください。カスタム例外クラスを作成し、さまざまなエラーシナリオを適切に処理したいと考えています。
Result型の実装 
JSONデータを解析するためのTypeScriptでのResult型パターンの実装方法を示してください。適切なエラー型とチェーン可能なエラーハンドリングを含めるしてください。
バックオフ付きリトライ 
ネットワーク呼び出し用の指数バックオフを実装するPythonデコレータを作成してください。異なる例外タイプを処理し、試行回数を設定可能にしてください。
サーキッドブレーカーパターン 
外部API呼び出し時にカスケード障害を防ぐためにPythonでサーキッドブレーカーパターンを実装してください。クローズ、オープン、ハーフオープン状態を含めるしてください。

ベストプラクティス

  • 入力を早期に検証し、文脈を含む意味のあるエラーメッセージを提供することでファストフェイルを実行する
  • スタックトレース、タイムスタンプ、関連するメタデータなど、エラー文脈を保持する
  • エラーに意味のある対応が可能な適切なレベルでエラーを処理する
  • エラーを適切にログする - 予期しないエラーをログし、予期される検証失敗はログしない

回避

  • Catching too broadly with generic Exception handlers that hide bugs
  • Empty catch blocks that silently swallow errors without logging or handling
  • Returning error codes instead of using proper exceptions or Result types
  • Ignoring async errors by not handling promise rejections properly

よくある質問

What is the difference between exceptions and Result types?
Exceptions are traditional error handling that disrupts control flow with try-catch blocks. Result types are explicit success/failure types that require the caller to handle both cases. Result types make error handling visible in the type system and are common in functional programming languages like Rust and Haskell.
When should I use a circuit breaker?
Use a circuit breaker when calling external services or APIs that might become unavailable. It prevents cascading failures by failing fast when a service is down, rather than tying up resources with repeated failing requests. The circuit transitions between closed (normal), open (failing), and half-open (testing recovery) states.
How does exponential backoff work for retries?
Exponential backoff increases the wait time between retry attempts (e.g., 1 second, 2 seconds, 4 seconds, 8 seconds). This prevents overwhelming a failing service with repeated requests while still giving it time to recover. Add jitter (random variation) to prevent thundering herd problems.
What is graceful degradation?
Graceful degradation provides fallback functionality when an error occurs. For example, if a caching service fails, fall back to the database. If both fail, return cached stale data. The application continues to work with reduced functionality rather than failing completely.
Should I catch exceptions or let them propagate?
Catch exceptions only where you can meaningfully handle them. Let unexpected exceptions propagate to a centralized error handler that logs them appropriately. This prevents hiding bugs with overly broad catch blocks while ensuring errors are properly logged and reported.
How do I create meaningful error messages?
Good error messages include what failed, why it failed, and what action to take. Include relevant context like user IDs, request IDs, and timestamps. Avoid generic messages like 'Error occurred' - instead say 'Failed to fetch user profile for user ID 123: connection timeout after 30s'.

開発者の詳細

作成者

sickn33

ライセンス

MIT

リポジトリ

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/error-handling-patterns

参照

main

ファイル構成

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md