1.この記事を書いた経緯
 2. 実装で問題が起きた際の対応マニュアル的なの
 ① 問題が起きた！！
② ログを見て、大まかな原因を確認する
 ③デバッグして落ちている箇所を確認する
 ③-1 ②で「ここが原因だ！！と原因が起きている場所の予想が付く」かつ「予想した箇所がソースコードにブレイクポイントが張れる」場合
 ③-2 3③-1以外の場合
 ④落ちている箇所でどんなエラーが出ているか・想定した値が入っているか確認
 参考サイト

1. この記事を書いた経緯

私はよく、ソースコードでエラーが出た！！・落ちた！とかの問題が起きた際に、「たぶんここが原因だ！！( ✧Д✧) ｶｯ!!」と予想という名の思い込みを発動する。
しかも、その予想はよく外れる。
その結果、 本当に問題が起きている箇所と見当違いの箇所を確認しに行き、エラーの解消に時間がかかり作業が遅くなる 。
本記事は、それを改善するために自分用の問題発生時マニュアル的な意味合いで執筆する。

2. 実装で問題が起きた際の対応マニュアル的なの

① 問題が起きた！！

Exceptionが出た(javaとかの場合)
webアプリの画面が表示されない・サーバからデータを取ってきて表示するはずの箇所が変
処理が落ちた
　　　　...etc

② ログを見て、大まかな原因を確認する

ログは、eclipseのコンソールや、ブラウザの開発者ツールのコンソールに出ている(場合によっては、webアプリの画面そのものにも出ている(404、500エラーとかの場合))
ここで、特に私は「たぶんこの辺がダメ」と思っても、ログの内容をよく間違える。
　(全く関係ないエラーを見て「エラー出てる！！きっとここが原因だ！！( ✧Д✧) ｶｯ!!」みたいな感じに)
　そのため、このままその場所をピンポイントで確認しに行くと危険。
　しかも下手すると、「エラー出てる！！きっとここが原因だ！！( ✧Д✧) ｶｯ!!。。。？んで、このエラーってどこを確認しに行けばいいんだ？？？(・∇・)？」となって、 どこを確認しに行けばいいのかをググりに行く。(←アカンやつ)

③デバッグして落ちている箇所を確認する

③-1 ②で「ここが原因だ！！と原因が起きている場所の予想が付く」かつ「予想した箇所がソースコードにブレイクポイントが張れる」場合

→原因だと予想を立てた箇所にブレイクポイントを張って、予想があっているかを確認する

予想を立てた箇所にブレイクポイントを張って確認することにより、「本当にそこで落ちている(エラーになっている)のか？」が確認できる
　そのため、もしブレイクポイントを張ったところで落ちていなかった場合、予想が違っていたことに気が付くことができる

③-2 3③-1以外の場合

→デバッグして、問題が起きている箇所(落ちている箇所)がどこなのかを確認しに行く
(「エラー出てる！！きっとここが原因だ！！( ✧Д✧) ｶｯ!!。。。？んで、このエラーってどこを確認しに行けばいいんだ？？？(・∇・)？」の場合もこっち)

Webアプリの場合の確認順序
- フロントエンド側・バックエンド側のどちらで問題が起きているのか切り分ける
  →通信をしている場合はブラウザの開発者ツールの「ネットワーク」を確認する
  　　・そもそも送信ができていない：フロントエンド側の問題
  　　・送信はできているがバックエンド側からの受信ができていない：フロントエンド側で送った情報にミスがあったか、バックエンド側の問題
  　　(フロントエンド側で送ったデータがミスっていないかどうかはブラウザの開発者ツールの「ネットワーク」で確認可能)
  　　(HTTPステータスコードで100番台、200番台、300番台は「正常」/400番台、500番台は「エラー」)
  　　・送信と受信両方できている：フロントエンド側の問題
- フロントエンド側で問題があった場合
  　・そもそも送信ができていない
  　　　→まず、バックエンド側と通信をするボタン押下時に実行される関数にブレイクポイントを張ってそこから順に追っていく
  　・送信と受信両方できている
  　　　→通信を受け取った後の処理の所にブレイクポイントを張る

jQueryでAjax通信をしている場合

$('#button_get_data').on('click', function(){
  $('#result').text('データ取得中...');
  // Ajax通信を開始
  $.ajax({
    url : '/ajax/example.html', // サーバーのURL
    type : 'GET',
    dataType : 'json', // サーバから返ってくるデータの種類 
	timespan:1000, // 通信のタイムアウト時間(ミリ秒)
  })
  .done(function(data) {
      // 通信成功時の処理
	  // 取得jsonデータの中の値を表示
	  $('#result').text(data["key"]); // ★ここにブレイクポイントを張る
	  
  })
  .fail(function() {
      // 通信失敗時の処理
	  $('#result').text('サーバからのデータ取得に失敗しました。'); // ★ここにブレイクポイントを張る
  });
})

バックエンド側で問題があった場合
　　・送信はできているがバックエンド側からの受信ができていない
　　　→フロントエンド側からの通信を受け取る所でブレイクポイントを張る
　　　　(javaだったらControllerクラスや、Endpointクラス)
デバッグするときは、意図した値が入っているか？をメモしながら進めていくといい
処理の流れが分からなくなる時は、(Excelとかで)簡単にシーケンス図を描くといい
　→どのクラスがどの順番で処理を行っているのかが整理されて混乱しにくくなる
　　例）Excelで簡単に描いたシーケンス図

④落ちている箇所でどんなエラーが出ているか・想定した値が入っているか確認

落ちた後にコンソールログへ発生したExceptionを出さずに握り潰したり、「処理に失敗しました。」といったざっくりとしたエラーしか出していない場合がある。
　また、try-catch文のcatchにて、捕まえる例外の型がざっくりとExceptionと定義されている場合もある。
　その際は、try-catch文のcatchの例外の変数(多くの場合は"e"で定義されている)の中身を見ると捕まえたExceptionの詳細が確認できる

コンソールログやソースコードを見ても何のExceptionか分からない場合

try {
    FileReader inputFile = new FileReader(exampleFileName); // テキストファイル読み込み
} catch (Exception e) { // ★ここの変数"e"を確認する！！(この場合は"FileNotFoundException"が入ってるからはず)
    System.out.println("処理に失敗しました。");
}

以上

思い込みは排除してソースログを確認しながらデバッグする習慣を身につける

目次