エラーの行は調査の入口。呼び出し元と入力までたどる
例外の種類・メッセージ・スタックトレースを一緒に読む。止まった行だけを直す前に、どこからどんな値が来たかを確かめる。
用語
- 例外
- 通常の処理の流れを中断して、失敗や想定外の状態を通知する仕組み。
- スタックトレース
- エラーに至る関数呼び出しを示す情報。表示形式や並び方は実行環境で異なる。
- 呼び出し元
- ある関数を呼び出し、引数を渡した側の処理。
図と例
例外の種類とメッセージを読む → 該当する自分たちのコードを開く → 呼び出し元と渡された値を確認 → 値の契約に合わせて修正する
仮定の例：formatCity内のaddress.cityでTypeError。呼び出し元のrenderProfileは、住所なしの会員にもaccount.addressを渡していた。住所が任意なら未登録の表示を設計し、必須なら入力・取得経路を直す。エラーの行番号だけでは、どちらが正しいか決まらない。
実際のサービス・製品では
解説
不具合調査で、エラーが観測された場所と、誤った値が作られた場所をつなぐ。例外を握りつぶして成功扱いにする前に、欠けた値が許される仕様なのかを確認する。
例外は、通常の処理の流れを中断して、失敗や想定外の状態を知らせるもの。スタックトレースには、そのエラーに至る関数の呼び出しが示される。まず種類とメッセージを読み、自分たちのコードの該当箇所と呼び出し元を探す。たとえばundefinedのプロパティ参照なら、参照した行だけでなく、その値を作った処理と入力の契約も調べる。ライブラリ内で止まっていても、渡した引数が原因かもしれない。表示の順序や形式は言語・実行環境で違い、JavaScriptのstack文字列も実装依存なので、常に一番上や一番下だけを読むルールにはしない。
トレードオフ
- デバッガーで失敗時の値を見る
- 得るもの：その場の引数や変数を詳しく確認できる
- 払うもの：同じ条件を再現できる環境が必要
- 必要な文脈を絞ってログに残す
- 得るもの：手元で再現しにくい失敗の手がかりを残せる
- 払うもの：記録項目と閲覧権限を決め、秘密や個人情報を含めない工夫が必要
さらに学ぶ
チェック
ライブラリ内でTypeErrorが出ているが、引数の正しさは未確認。次に何を調べる？
- ライブラリが壊れていると決めて全面的に置き換える
- スタックから呼び出し元を探し、引数とAPIの契約を照合する
- すべての例外を無視して成功を返す
解答と解説
スタックから呼び出し元を探し、引数とAPIの契約を照合する
発生箇所と原因の発生箇所は同じとは限らないので、渡した値を確認する。ライブラリの欠陥は候補の1つだが、場所だけでは断定できない。例外を無視すると、処理に失敗した事実まで隠してしまう。