エラー恐怖症を克服する 〜エラーは友達〜

要約

• エラーは開発を手助けしてくれる
• 気軽に実行しよう
• エラーメッセージを読もう
• エラーメッセージを書こう

この記事を書いた背景

プログラミングを始めてから数年の間、自分にとってエラーは憎いものでした。 何をするにもエラーは付き物です。 プログラムを実行しているときやコンパイル時、アプリケーションを使っているときなど数えると終わりがありません。
自分が開発してるときは特にエラーが嫌いでした。 それは以下の理由からです。

• プログラムが動かなくてフラストレーションがたまる
• エラーが怖い

プログラムが動かなくてフラストレーションがたまる
自分が書いているプログラムはほとんどエラーによって停止します。 この時の自分はエラーが自分のプログラムを止めている元凶だと思っていました。 コードを書いて意気揚々と実行するとエラーによって止まるわけです。 テンションも下がりますし、直すのも手間がかかります。

エラーが怖い
エラーが発生した時には大体エラーメッセージが付き物です。 自分はコンソールを埋め尽くすようなメッセージの前に立ち尽くしていました。 そんなことを繰り返しているうちに次第にプログラムを実行するのが怖くなり、開発の速度も落ちてしまいました。

エラーが起きないことを神に祈りながらプログラムを実行していました。 この記事では便宜的にこういった症状を「エラー恐怖症」と呼びます。
つまるところ自分にとってエラーとは快適な開発を邪魔する敵でしかなかったのです。 しかし、視点を変えてみるとそれは違うことに気付きました。 以下では以下の2点について書いていきます。

• エラー恐怖症を克服するために
• エラー恐怖症を克服したあとに

エラー恐怖症を克服する

エラーは友達

現在の自分にとってエラーとは一緒に開発を進めてくれる友人のようなものです。
開発時点でエラーが起きるのは幸せです。 そもそも、エラーは本来の想定と違う場合に発生し、その時点で何らかの問題があることが明らかになります。

エラーがない世界を考えてみましょう。 システムに不整合を起こさせるような不具合があったら、それを知りたいですよね。 もし、何も知らない状態で運用され、何かのきっかけで不整合がおきたとしたらどうなるかは未知数です。 運が良ければプログラムが停止するだけで済むかもしれませんし、最悪の場合大切なデータが破損するなども考えられます。

また、ほとんどの場合プログラムが動かないことの責任は自分にあります。
想定と異なった使用法でライブラリを導入しているかもしれませんし、文法ミスでコンパイルできないという自体もあります。
エラーが起きる状況というのはそもそも想定通りに動いてないので、実行できていても見せかけでしかありません。 後々気づく問題を先に教えてくれるのでエラーは親切なものだと自分は思っています。

そう考えると恐ろしいエラーメッセージへの態度も変わってきます。

エラーメッセージを読む

エラーが発生したことによってプログラムに問題があることはわかりました。 これを直すのに役立つのがエラーメッセージです。

エラーメッセージを読めば問題の原因がわかることがあります。 何が起きたのかや、幸運であれば対処法が書いてある場合もあります。 威圧的だったエラーメッセージも実は自分を助けようとしてくれていたことに気付きます。

自分にとってエラーメッセージは直すべき箇所を教えてくれる親切なものです。 例えば、何らかの理由でプログラムが停止した時に、なにも表示されなかったら困ります。 どこから手をつけていいのかわかりません。

エラーメッセージの有用性に気づきましたが、途方に暮れるというのはまだ変わっていません。 それはエラーメッセージとの関わり方をまだ知らないからです。

エラーメッセージと向き合う

個人的なエラーメッセージの克服法は分解することです。
一見複雑に見えるエラーメッセージも分解していけば読み解けることがほとんどです。 そうして分解していけば長大なエラーメッセージであっても問題の核心となる部分が明らかになります。 この段階でコードの問題に気づく時もありますが、そうでない場合の個人的な対処法を下に書いておきます。

エラーが起きた場所を特定する
スタックトレースなどからどこでエラーが起きたのかをはっきりさせましょう。 エラーが起きた場所がはっきりしたら、言語やライブラリのリファレンスを参照すれば解決できる場合があります。 OSSの場合はソースコードを参照してロジックを確認するのも一つの手かもしれません。

検索エンジンで調べる
何分からないエラーでも検索エンジンを活用すれば解決できる場合があります。 個人的には最初はエラーメッセージをコピペして検索するだけでも十分だと思います。 StackOverflowやブログなどに解決法が載っている場合があります。 それでも出てこない場合は、自分の言葉で問題点を解決するようなワードで検索するのが良いでしょう。 この時英語で検索するとより効果的だとおもいます。

エラー恐怖症を克服したあとに

エラー恐怖症を克服したあとに変わったのは以下の3つの点です。

• 頻繁にプログラムを実行する
• エラーに備える
• エラーメッセージをしっかり書く

頻繁にプログラムを実行する

エラーが怖くて迷っている暇があるならその分だけプログラムを実行した方が良いと思います。
熟孝すれば遭遇するエラーの数は減らせるかもしれません。 しかし個人的な感覚としてはプログラムを実行した方が、開発が早く進む場合があると思います。
チュートリアルやリファレンスを読んでいるだけでは分からないことは多いですし、実際大量にコードを書いた後に問題が発覚した場合には手戻りが生じる可能性があります。 そのため、問題を小さな単位に分割しその都度実行し開発してくことがマイブームです。
もちろん、頻繁に実行すればエラーに遭遇する頻度も増えると思います。 しかし、開発中にエラーが起きても責める人は誰もいません。 それどころかエラーは開発を手助けしてくれます。

ここまで書きましたが頻繁に実行しない方がいい局面があります

注意点

• 本番環境
  • 本番環境では安易に行動するとシステム全体を止めることになりかねません
  • 開発環境や場合によってはテスト環境で実行するのが良いでしょう
• 時間のかかる処理
  • 時間のかかる処理では待ち時間が多くなってしまいます
  • 可能なら処理時間を減らして実行するのが良いでしょう（データ数を減らすなど）

エラーに備える

ここで言う「備える」とはロギングやエラーハンドリングのことです。
エラーが起きないシステムを作ることは困難です。 プログラムが完璧であってもOSやハードウェア、DBなど様々な要因からエラーが発生します。 こんな時エラーが発生したことを知る必要があります。 そうでなければ、原因の発見は難しくなると思います。
そういった時便利なのはログをとることです。 ログを取っておけば後から調査することができます。

エラーハンドリングはプログラム言語レベルでも、システムレベルでも可能だと思います。 言語レベルでは例外処理の機能を適切に使えばある程度は実装できると思います。 またシステムレベルではプロセスの終了コードをチェックしプロセスを再起動するだとか、サーバーへのヘルスチェックを行い異常だった際には予備のサーバーに切り替えるなどが考えられます。 こうして例外が起きた場合の流れを決めておくことでシステムの健全性を保つことができます。

エラーメッセージをしっかり書く

もしエラーを送信する機会があるなら親切なエラーメッセージを書くのを心がけましょう。 あなたがエラーメッセージで助けられたように、あなたが送信するエラーもまた誰かを助けます。
ここでは開発者が目にするようなエラーメッセージについて話していきます。 個人的に心がけているのは以下の3つです

• 起きたことを簡潔に
• 値を出力する
• 解決するヒントを書く

起きたことを簡潔に
自分のコードが何を想定していて、何が起きたのかを簡潔に書きましょう。 感覚としてはエラーにタイトルをつけるようなものです。 全体の概要が掴めるようなメッセージを書くのが良いでしょう。

値を出力する
エラーに関連する値を出力するとデバッグに便利だったりします。 エラーの原因となっている値やスタックトレースなどを出力すると問題の発見がしやすくなります。

解決するヒントを書く
もし、エラーを送信して、その問題の原因がある程度予測できるなら解決策も一緒に書いてあげると親切です。 例えば「設定ファイルが存在するか確認してください」などです。

感想

昔は漠然とプログラムを実行するのにプレッシャーを感じていました、 その原因を突き詰めていくとエラーに対する恐怖感がありました。 これと向き合うことでより良い状態でコードが書けるようになったと思うので、振り返りがてらまとめました。