JavaScript/エラー処理/Lesson 18
エラー処理 — try/catch/finally + カスタムエラー
45分·theory
エラー処理 — try/catch/finally + カスタムエラー
🎯 このlessonを読み終えたら
このlessonを読み終えると、以下の3つを自信を持ってできるようになります。
- ▸✅ try / catch / finally + Error.cause (ES2022)
- ▸✅ カスタムエラークラスによるドメイン例外の分離
- ▸✅ async関数のエラー処理 + unhandledrejection
学習目標をチェックリストとして持ち、すべて答えられるようになったらlessonを閉じてください。
try / catch / finally — 基本構造
最もシンプルなtry-catch
エラーがthrowされると、上のコードは即座にcatchブロックへジャンプします。throwされなければcatchはスキップされます。
finally — 成功・失敗にかかわらず実行
リソースの解放(DBコネクション・ファイル・ロック)の標準パターン。
Errorオブジェクトの4つの情報
よく見るエラーの種類4つ
- ▸TypeError —
null.foo、undefined()— 最もよく遭遇するエラー - ▸ReferenceError —
consle.logのような存在しない変数の参照 - ▸SyntaxError — 構文そのものが壊れている(通常はビルド段階で検出)
- ▸RangeError — 配列の長さが負の値・無限再帰
エラーメッセージをそのままAIに見せると、ほとんどの場合原因を指摘してくれます — これが「デバッグのトークン節約」の核心です。
カスタムエラークラス — ドメインごとの分離
なぜカスタムエラーが必要か
すべてのエラーをError一つでthrowすると — catch内で原因ごとの分岐が難しくなります。カスタムクラスで分離しましょう:
分岐処理
instanceofで型による分岐。コードの意図が明確になります。
ES2022 cause — エラーチェーン
元のエラーを保持したまま新しいエラーでラップします。ログに元のスタックトレースも残り、デバッグが容易になります。
async / await でのエラー処理 — 標準3パターン
パターン1 — async内のtry/catch
最もよく使われる形。fetchは4xx/5xxでrejectしません — res.okまたはres.statusを自分で確認する必要があります。
パターン2 — Promise.catch()
async関数でない場所(イベントハンドラなど)で使用。async/awaitと混在させることも可能です。
パターン3 — そのまま上位に投げる
ドメインロジックの関数はtry-catchを使いません。責任は最上位の呼び出し元(コントローラ・UIコンポーネント)に委ねます。
よくある落とし穴 — forEach内でのawait
forEachはPromiseを認識しません。for...ofに切り替えましょう:
React Error Boundary — UIエラー処理
レンダリング中のエラーをキャッチしてアプリ全体がクラッシュするのを防ぎます。try-catchはレンダリングエラーを捕捉できません。
🤖 AIへのリクエスト例
- ▸「このfetchコードにres.okチェックとtry-catchを追加して」
- ▸「このエラーをNotFoundError・ValidationErrorに分岐して処理して」
- ▸「forEachのawaitが動かないのでfor...ofに変えて」
⚡ 実際に試してみよう — try · catch · finally + カスタムエラー
エラーの種類ごとの分岐処理。instanceofでどのエラーかを判別します。
✏️ JS 코드
📟 コンソール出力
▶ 実行ボタンを押してください
⚠️ ブラウザのサンドボックスで実行 — console.log()のみ対応、alert/fetchは不可
先に読むとよい概念: Async/Await
次のおすすめ: ES2022〜2025 最新構文 — AI生成コードの定番