【初学者向け】個人的に考えるエラーの原因特定〜解決策までの考え方

概要

エラーの原因特定〜解決策に至るまでの考え方についてまとめてみました。

先日エンジニアの方に、ポートフォリオのエラーを見ていただく機会がありました。
その時学んだこと、普段の体験をもとに、書いていきます。

本記事の目的は以下の通りです！

• 自分のアウトプットのため
• 同じ境遇の方にとって、何か参考になればと思ったため

前提として、
原因の特定の仕方はたくさんあると思います。
また、本記事の通り行えば、必ず原因が特定できるとも限りません。
そこはご了承ください。

なお、プログラミング初学者の方向けに書いています。（そして筆者も初学者です）
まだまだ至らぬ点もあるかもしれません。
こうした方がいいよ！などあれば、コメントをいただけると嬉しいです！

環境

• macOS (Catalina 10.15.7)
• ruby (2.6.5)
• rails (6.0.0)
• MySQL (5.6)

原因の特定方法

[前提]
ここでいう原因の特定方法とは、筆者が学んだこと、体験をもとにした方法を指します。

原因の特定方法は以下の通りです。
特定できるまで繰り返します。

1. エラー文を表示させ、悪さしている箇所を予測する。
2. 該当するコードのどこが悪さをしているか突き止める。

では、それぞれについて詳細を記載していきます。

1、エラー文を表示させ、どこが悪さしているか予測する。

エラー文は以下の方法で確認できます。

• ブラウザに表示される赤いやつ（うわぁとかんじるやつ）
• コンソール上で出す

コンソールでエラー文を表示させるには、以下のメソッドを使用します。

• .valid? (正しく保存されるかを確認するメソッド。trueもしくはfalseが返ってくる。)
• .errors（エラーを表示させる）
• .full_messages（エラー文を表示させる）

以下の例を用いて、上記メソッドの使い方を記載します。

例）hogeモデルとfugaモデルで中間テーブルを組み、保存できるか確認する。

pry(main)> hoge = Hoge.create(name:"ほげ", fuga_ids:[1,2]) #変数hogeに作成した物を代入。

pry(main)> hoge.valid?                                    #hogeはバリデーションに引っかからず保存できたか確認する。
=> false                                                  #True もしくは Falseが戻り値で返ってくる。

pry(main)> hoge.errors.full_messages                      #.errors.full_messagesと使用することで、エラー文が表示される。
=> fugas is invalid

流れとしては、valid?で保存できるか確認する
↓
falseなら、errors.full_messagesを使ってエラー文を表示させる。
と言った感じです。

今回は、fuga is invalidというエラー文を確認できました。

２、該当するコードのどこが原因か突き止める。

ここでは、以下の順番で原因を突き止めます。
1. エラー文から、原因はどのあたりか予測する。
2. 仮説検証する。

それぞれについて、記載していきます。

エラー文から、原因はどのあたりか予測する。

まずはエラー文から、エラーの原因はおそらくこのあたりだろうな、と予測します。
イメージとしては、進む方向をざっくり決める感じです。（西に進むのか北に進むのかレベルで大丈夫です。）

個人的には、以下のどれっぽそうか考えます。

• コントローラー
• モデル
• ルーティング
• ビューらへん

先の中間テーブルの例を使って予測すると、モデルが怪しいのではないか？となります。
怪しいと考えたプロセスは以下の通りです。

1. 「is invalid」とググってみる。
2. ふむふむ、バリデーションに関する記事が多く出てくるぞ？
3. railsガイドのバリデーションのエラー文にて、「is invalid」を発見
4. バリデーションてことは、モデルなのかな？

と言った感じです。

仮説検証する

先ほど予測した箇所のどこが悪さをしているか突き止めていきます。
個人的に仮説検証は以下のように考えています。

• 原因を突き止めるまでとにかくやりまくる
• あれこれ考えすぎず、エラー文から素直に考える。
• 途中詰まってしまったら、A4用紙を使って思考を整理する。

先の中間テーブルの例を使って仮説検証するとしたら、

• そもそも、各テーブルのレコードは作成できるだろうか？（コンソールを使って作ってみる）
• バリデーションが悪さしているなら、消してみたらどうなるか？（バリデーションの記述を消してみる）

といった感じです。

ちなみに、A4用紙を使って思考を整理する方法は
こちらをご覧ください。

解決策の考え方

ここでは、解決策の考え方について記載します。

以下の考え方を使い、解決策を考えると学びました。

1. 原因を取り除く
2. 原因を迂回する

原因を取り除く
原因となっている箇所を変更して、取り除いてみるといった感じです。
基本的には、これをもとにして解決策を考えます。

原因を迂回する
原因を迂回してエラーを発生させないようにするといった感じです。
時には、原因不明のエラーが出てしまうこともあります。
そういったどうしようもないときには、原因を迂回します。

ちょっと極端ですが、
先の中間テーブルの例を使ってみると、

原因を取り除く
→例）他のやり方に変更する。

原因を迂回する
→例）validates:falseを使ってスキップする。

と言った感じです。

さいごに

最後まで読んでいただき、ありがとうございました！

読んでいただいた方の中で、

• こうしたらうまくいったよ！
• 自分はこうしているよ！

などあればコメントいただけると幸いです！