概要
この記事はエラーメッセージの役割とフォーマットの工夫について書きました。
本文はとても短いので、ご飯のお供にでも気軽にお読みください。
エラーメッセージの役割
プログラムの実行で異常を検知した場合に、警告やエラーメッセージを出力することがあります。エラーメッセージには以下のような役割があります。
- 処理の実行中に異常、問題があったことを伝える
- エラー発生の原因を伝える
- 追跡する為の情報を伝える
- 問題を解決する為のヒントを伝える
エラーメッセージは蜘蛛の糸
メッセージは開発者のメモ書きでは無いので、何を伝えるのかを明確にし、伝え方の工夫が求められます。開発者がとりあえず何か出しておくか…のようなノリで実装していると、本人が思っている以上にそのコードが長く残り続けていたり、想定以上の活用のされ方をしたりして、そのメッセージの質が後々技術的負債にまでなってしまうことだってあります。
システムやプログラムを利用する側は、エラーメッセージこそ、問題解決の最も重要なヒントとして捉えています。藁にもすがる思いでそのメッセージをヒントに問題解決を図るので、出来るだけ利用者の助けになる出力を心がけましょう。
利用者の助けになるメッセージを心がける
フォーマットの工夫
例えば以下のようなケースを考えます。
- リソースを読み込む処理中で、指定されたデータが見つからなかった
二つの例文を考えてみます。
The specified resource 'A' was not found.
The specified resource was not found. resource:A
どちらが良さそうでしょうか。状況を伝えるだけでしたら大差はありません。しかし、後者の方がより二次活用をしやすいという点で優れています。
例えばこのプログラムが世の中で広く公開されているもので、類似のトラブルが無いか検索しようとします。その際に、リソース名を表すAという部分は可変になるので、前者の場合だと検索の仕方に工夫が必要になる場合があります。
同様にエラーの統計を取ろうとした場合に、やはりメッセージの途中にある可変部分を塗り潰すなどしないと、別のエラーとしてカウントされてしまいます。後者であれば、例えばピリオドまでの前方一致でエラーをまとめられたりします。
エラー内容を表す本文と、具体的なIDやEntityを指すテキストは分離して表現すると、よりエラーを活用しやすくなる
終わりに
この記事ではエラーの本文については触れませんでしたので、そちらの工夫も機会があれば書きたいと思います。皆様がステキなエラーメッセージライフを過ごされますように。