ただし、ログ解析をするときはエラーコードがあった方が望ましい。
ログ解析では個々のエラーの件数を数えることをほとんどの場合で行うと予想されるがその時のログ抽出条件として一意のエラーコードで抽出するのが合理的。
エラーメッセージそのもので抽出する場合はエラーメッセージがユニークであることを保証しなくてはならないが実装者間でそれをやり取りするのは困難である。その他の一意な文字列で抽出することは可能かもしれないがグラフ化したときに凡例には短いエラーコード文字列で記載された方が便利であるためエラーコードを使用する。
つまりエラーコードは人間の理解のためではなく解析的メリットのために存在するのではないだろうか。
※ORA-ERRORを見るとエラーコードは上記のためではなく人間がそれをキーに検索をして内容を知るような設計になっているがこれはキーを元に多言語化されたエラーメッセージを引く要望があるからだと思われる。エラーメッセージを多言語化したいならException発生時にはメッセージキーのみを決定されることになりこのメッセージキーは簡潔で一意の文字列になるべきである。
よく同じような内容のエラーではソースコードの異なる場所でも同じエラーコードを使いまわす例があったがこれは使いまわす条件を定義するのが困難であるためやるべきではない。
必要に応じて解析ツール側でグルーピングを行った方が安全であるように思う。
エラーコードは基本的にMyExceptionのコンストラクタで定義する。
Javaコードを編集してエラーコードを埋め込むエラーコード管理ツールを作成し、それは以下の機能を持つ。
- MyExceptionのコンストラクタの引数に一意にエラーコードを振る。
- 採番したエラーコードとエラーメッセージの組みをCSVに出力する。
ログに出力したいエラーはすべてMyExceptionでラッピングすることをルールとする。SQLExceptionであろうとなんであろうとログに出力したい場合はすべてMyExceptionのコンストラクタに食わせることを
ルールとする。
このツールはbuild.xmlなどから呼び出して本番用バイナリをビルドするときにエラーコード管理票を出力し、ビルドバージョンとともに管理する。その時に毎回全部やっていると大変なので、引数に
パッケージ名を指定できるような仕様にしておくと良さそう。
と言ってみたもののまだまだ問題がありそうですね。
この辺はみなさんどう対応してますか。
投稿
