エラーとは何か
☆ エラー
① 「何が悪いのか、どこが悪いのか」という指摘は、エラーメッセージに書いてある
→まずはエラーメッセージをよく読む事が大事
② 原因を理解した上で修正する
(なぜなら、原因が分からないまま修正して動いたとしても、また同じエラーに悩まされるだけだから)
③ エラーはスキルアップのチャンス
熟練プログラマは頭の中に「エラーを起こした失敗経験と、それを解決した成功経験」の記憶の引き出しをたくさん持っている
・・・似たようなエラーに悩んだ経験があるから出来る
・コンパイルエラーの読み方
>javac Main.java
Main.java:5 : 変数は初期化されていません;
↑エラー発生場所 ↑エラー本文
☆ コンパイルエラーが一度に2つ以上あった場合は、上から着実に修正していくこと
…なぜなら、最初のエラーが原因で2番目のエラーが誘発されていることが少なくないから。
・スタックトレースの読み方
>java Main
Exception in java.lang.NumberFormatException:null
at java.lang.Integer.parseInt(Unknown Source)
↑エラーが起きた直接的な要因
at sub process(sub.java:3) //sub…クラス名 process…メソッド名
↑最も怪しむべき間接要因
at Main.caller(Main.java:28)
at Main.main(Main.java:6)
☆ スタックトレースは下から上に向かって読んでいく
翻訳「Mainクラスのmain( )の内部でMainクラスのcaller( )を呼び、その内部でsubクラスのprocess( )を呼び、
その内部でIntegerクラスのparseInt( )を呼んだところ、例外が発生した」
〈解決までのプロセス〉
① まず、先頭行を見て発生した例外の種類と詳細情報を確認し、
「 何が起きたか」を把握する
今回:NumberFormatException:null→「数字の形式がおかしい(nullであった)」と推測
②「どこで起きたか」を把握するために、次の行(atから始まる最初の行)を見る
(この行に記述があるクラスおよびメソッド内で例外が発生している
「例外の直接原因となった場所」)
③その行を見ても問題が見つからなかった場合や、その行がAPIメソッドである場合は次の行を見る。
:バグを探す根本の考え方は「このメソッドを呼び出した元が悪かったのではないか」と仮定すること
よって、あらかじめAPIとして準備されているメソッドにバグがあるとは考えにくい
④直接原因となっているメソッドを呼び出している「subクラスのprocessメソッド」を例外の間接要因として着目する
(このクラスはAPIクラスではなく、自分が開発しているクラスであるため、誤ったコードが含まれている可能性が比較的高い)
⑤もし、そのコードに問題がなければ、それを呼び出している元メソッドコード(次の行)に誤りがないかを検証する
:
(この作業を繰り返していく)