# エラーメッセージは 2W1H がいいんじゃないか

{{tag: development, log}}

## 良くあるダメなエラーメッセージ

エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。

    $c->log->error('something wrong!');

ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。

    $c->log->error('error!');

本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。

## 機械的なエラー情報

そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。

 * 発生時刻
 * 発生場所
 * stack trace
 * 変数の状態

ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多かったりします。エラーが起きているからにはなんらか利用者に影響があると思うのですが、そもそも何が起きているのか、なぜ起きているのか、即時対応が必要か、あとで対応でいいのか、実際対応するとなったときどういう対応が必要なのか、その辺全てさっと把握するのは難しかったりする。発生頻度の低いエラーほどそういう傾向があると思う。

## エラーメッセージに必要な 2W1H

だから、Logger のインターフェースをこんな感じにしとけば良いんじゃないかと思う。

    $c->log->error(
        what => 'What happened?',
        why  => 'Why did this happen?',
        how  => 'How can we support this?',
        info => Dumper($some, $information),
    );

情報伝達の基礎であるところの 5W1H を 2W1H に絞ってインターフェースで強制する感じ。たいてい、わけのわからないエラーメッセージはこの 2W1H のうちのどれかしか書かれてないし、How まではふつうさすがに書かないと思うし。でも、書かれてることで助かる場面というのは多いだろうと思う。またこのような記述がされていれば、コードレビュー時点でメッセージを見て本当に必要なエラーであるかとか処理のよしあしとか、またその対応についてまで議論がしやすいと思う。

自分のこれまで見てきたプロジェクトのエラーログとかと比べるといささか冗長なのだけど、やっぱあとで困るの嫌だし、こういうのいいなと最近思ってる。

ちなみに、こういうデータ構造にしなくても単純なメッセージのインターフェースで 2W1H 情報を盛り込めるのが一番良いんだけど、それはなかなか難しいなという感触をもとに書いております。