今回やること
この記事では、DevToolsのConsoleに出るJavaScriptエラーを読む順番を整理します。
Consoleは、JavaScriptがどこで止まったかを見る場所です。
Step 1: エラーを怖がらず分解する
Consoleの赤いエラーは長く見えますが、見る場所は決まっています。
例:
TypeError: Cannot read properties of null (reading 'addEventListener')
at main.js:12:8
まず次の4つに分けます。
| 部分 | 意味 |
|---|---|
| TypeError | エラーの種類 |
| Cannot read… | 何が起きたか |
| main.js | どのファイルか |
| 12:8 | 何行目・何文字目か |
Step 2: エラー名を見る
よく見るエラー名:
| エラー名 | よくある原因 |
|---|---|
| TypeError | 値の型や中身が想定と違う |
| ReferenceError | 変数が存在しない |
| SyntaxError | 文法が間違っている |
| RangeError | 範囲外の値を使った |
エラー名だけで原因が決まるわけではありませんが、調査の入口になります。
Step 3: メッセージを読む
次に、エラーメッセージを読みます。
Cannot read properties of null
これは、null に対して何かを読もうとしたという意味です。
よくある例:
const button = document.querySelector("#submit");
button.addEventListener("click", () => {});
#submit が画面に存在しなければ、button は null になります。その状態で addEventListener を呼ぶとエラーになります。
Step 4: 行番号へ飛ぶ
Consoleのエラーには、ファイル名と行番号が表示されます。
main.js:12
クリックするとSourcesパネルで該当行へ移動できます。
確認すること:
- その行で何をしているか
- 変数の中身は想定通りか
- DOM要素は存在するか
- APIレスポンスの形は想定通りか
Step 5: stack traceを見る
複数行のエラー表示は、呼び出し履歴を表していることがあります。
at handleClick (main.js:20)
at HTMLButtonElement.<anonymous> (main.js:35)
上から下へ「どこでエラーが起きたか」「どこから呼ばれたか」を確認します。
最初は一番上の自分のコードを見ることが多いです。ライブラリ内部の行が出ている場合も、原因は自分の渡した値にあることがあります。
Step 6: console.logで確認する
原因が分からない場合は、該当行の前に console.log を置きます。
const button = document.querySelector("#submit");
console.log(button);
null と表示されたら、セレクタかHTML側を確認します。
ただし、調査が終わったら不要な console.log は消します。
よくあるパターン
| エラー | よく見る場所 |
|---|---|
Cannot read properties of null | DOM要素がない |
is not defined | 変数名・import忘れ |
Unexpected token | 文法ミス、JSONではないレスポンス |
Failed to fetch | API URL、CORS、Network |
実践メモ: Consoleのエラーは、全文を貼るより「エラー名、メッセージ、ファイル名、行番号」を分けて整理すると質問しやすくなります。
まとめ
Consoleのエラーは、エラー名、メッセージ、ファイル名、行番号、stack traceの順に読みます。
JavaScriptが動かない時は、まずConsoleを開き、該当行の変数やDOM要素を確認します。Networkの失敗が原因でConsoleにエラーが出ることもあるため、必要に応じてNetworkも合わせて見ます。
次に読む記事
ケース：nullのプロパティ参照
Cannot read properties of null (reading 'textContent')ではtextContentを変更する前に、左側がなぜnullかを調べます。messageは失敗操作を示しますが理由までは示しません。最初の自作frameへ移動しselector、HTML、実行時点を照合します。
IDのタイプミスなら常にnull、scriptがHTMLより先ならDOMContentLoaded後だけ成功、特定pageだけ要素がないなら共通scriptの適用範囲が問題です。Elementsで存在を確認し、breakpointで取得直後の値を見ます。
optional chainingは例外を消しますが、必須要素の欠落まで隠します。任意要素という仕様なら使い、必須ならselectorや読込順を直します。asyncではcauseを展開しreject処理とawait元を追います。Network失敗なら該当requestへ移ります。修正後は表示更新も正常で、listener重複による再発がないことを確認します。
Console表示を誤読しない補足
warningとerrorを区別します。deprecation warningは即停止でなくても更新時の破壊につながるため発生packageを記録します。extension由来はsource URLを見てapplicationと混同しません。
objectは後から展開するとlog時点でなく展開時点の値に見えることがあります。必要なIDや長さをprimitiveで出します。DOM nodeも現在状態へ結び付くため更新前後を区別します。
productionでsource mapがなければminified位置しか出ません。release artifactとmapのversionを合わせます。catchして空にするとConsoleは静かでもdata欠落を隠します。catchには回復処理、利用者表示、監視を設計し、処理結果が仕様どおりかで判断します。
Consoleへ直接式を入力する時は副作用に注意します。関数呼出しがdata更新やrequest送信を行うなら、確認のつもりで状態を変えます。まず変数参照やread-onlyな式を使い、production dataへ影響する操作は実行しません。
filter欄でmessageを絞った後は解除して関連warningも確認します。選択contextがiframeやworkerになっていると、top pageの変数が見えません。execution context、page URL、source fileを合わせてから「値がない」と判断します。
エラー種別ごとの判断表
| 表示 | 最初の問い | 開く場所 |
|---|---|---|
x is not defined | 宣言・importしたか | 最初の自作frame |
properties of null | nullになる取得は何か | DOM取得や検索結果 |
is not a function | 実体と期待型は一致するか | 呼出直前とexport |
Uncaught (in promise) | rejectを誰が扱うか | async呼出元 |
SyntaxErrorは実行前の解析、ReferenceErrorは名前解決、TypeErrorは値を使う段階の失敗です。stack traceは修正一覧ではなく、例外が伝わった経路です。 library内部より先に最初の自作frameで引数と戻り値を確認します。
Consoleでの確認方法
画面遷移で消える場合だけPreserve logを使い、開始前にclearします。同一messageが連続する時は最初の一件を優先します。後続は初期化停止による二次エラーかもしれません。ログへtokenや個人情報を出さず、objectの後展開で状態が変わる場合は必要なprimitive値を記録します。修正後は別例外へ置き換わらず正常画面も保たれることを確かめます。赤い行より、最初に壊れた値が期待どおりになったかを確認します。
