error-handling

原文涵盖的主题

• エラー処理パターン
• アクティベートするタイミング
• コア原則
• TypeScript / JavaScript
• 型付きエラークラス
• Resultパターン（スロー不使用スタイル）
• APIエラーハンドラー（Next.js / Express）
• ReactエラーバウンダリーII

本番アプリケーション向けの一貫した堅牢なエラー処理パターン。 新しいモジュールやサービスのエラー型や例外階層を設計する場合 信頼性の低い外部依存関係に対してリトライロジックやサーキットブレーカーを追加する場合 APIエンドポイントでエラー処理の欠落をレビューする場合 ユーザー向けエラーメッセージとフィードバックを実装する場合 カスケード障害やサイレントなエラー飲み込みをデバッグする場合 1. 早く大きく失敗する — エラーが発生した境界で表面化させる。埋め込まない 2. 文字列メッセージより型付きエラー — エラーは構造を持つファーストクラスの値 3. ユーザーメッセージ ≠ 開発者メッセージ — ユーザーには親しみやすいテキストを表示し、詳細なコンテキストはサーバー側でログに記録する 4. エラーをサイレントに飲み込まない — すべてのcatchブロックは処理、再スロー、またはログのいずれかを行う必要がある 5. エラーはAPIコントラクトの一部 — クライアントが受け取る可能性があるすべてのエラーコードをドキュメント化する 失敗が想定され一般的な操作（パース、外部呼び出し）向け: エラーコードを人間が読めるメッセージにマッピングする。技術的な詳細はユーザーに見えるテキストに含めない。 エラー処理に触れるコードをマージする前に: [ ] すべてのcatchブロックが処理、再スロー、またはログを行っている — サイレントな飲み込みなし [ ] APIエラーが標準エンベロープ{ error: { code, message } }に従っている [ ] ユーザー向けメッセージにスタックトレースや内部詳細が含まれていない [ ] サーバー側で完全なエラーコンテキストがログに記録されている [ ] カスタムエラークラスがcodeフィールドを持つ基底AppErrorを継承している [ ] 非同期関数がエラーを呼び出し元に伝播している — フォールバックなしの fire-and-forget なし [ ] リトライロジックがリトライ可能なエラーのみをリトライしている（4xxクライアントエラーはリトライしない） [ ] ReactコンポーネントがレンダリングエラーのためにErrorBoundaryでラップされている