前回、ログ考えるの、もうめんどいから必要だと思ったらその時点で都度出したい、って方針だとダメなケースがあったりする。
ログを監視するとき、行ベースで監視してたりすると、1行エラーログあれば1回、2行エラーログがあれば2回といった感じに出てくる。
この辺、なんも考えなしにログ出してると、共通の処理で1回、呼び出し元で1回・・・みたいな原因は1か所なのにログが2回出るという謎の状態になる。俺だ。
コレの何が不便って、お仕事だとこの問題に対してなぜ起きたかを理由づけしてナレッジに送らないといけない。そうすれば同じエラー出た時にこんな対処でいいんだね、と参考にできるから。でも1回の操作で10件ものエラーが出たらつらい。
話は変わって、ユーザには成功したか失敗したかを返せば良い。
外部連携とかしたりしていい感じに処理したり、リトライしたりした結果、成功しました！みたいなレスポンスはどうでもよい。
なら、レスポンスを返すところで、失敗したのであればその失敗の内容をエラーログを出せばよいのでは。
それならどんなことがあってもログを出せるタイミングはその1か所のみに絞れる。ユーザの1リクエストの単位で1エラー出すこともできる。
・・・失敗と抽象的な表現にしちゃったから内容なんてわかんにゃーい☆みたいな実装してることもある。俺だ。
それに実際はエラーを積み上げて表現したくなったりする。共通処理の呼び出し元で微妙に原因が違うから。ああ、面倒。共通化間違ったかな。
戻り値やBeanだと呼び出し元にしか返せない。呼び出し元でチェックしてくれるか不安。エラーを表現するのは面倒だし、チェックする側も面倒。
なら例外を使ってもよいのでは。共通に投げる例外を決めて、例外が出た時は失敗にするんだ。例外には原因となったメッセージと、必要な情報を持たせろ。いいな？
とか言い始めると「これ、準正常系だから。エラーじゃない」とか言い始めるやつが出る。俺だ。
じゃあ、準正常系を表現するステータスを持たせましょう、例外のクラスを切りましょう、どうでしょう？
そんな感じに辛くなりながらライブラリを書いてると「処理的にはエラーになる可能性が起こるのを承知してるし、こっちでハンドリングしたいから戻り値で表現してくれ。勝手にログを出すな。try-catchめんどい。」って話もある。ならもうdebugログ以外出さないから手前で勝手にやれよってなる。
基本的にログは出すが、どうしても嫌ならロガーの制御で特定のライブラリだけ黙らせてはどうか。でもユーザが面倒なことしなくちゃいけないライブラリは俺が許せない。
でもそうするとチェックが甘々になって、実装もガバガバになる。
結局どうすりゃいいんだ。楽で適切な方法はないんか。1粒で2度おいしい的な。
個人的には例外投げて500で返すぐらいガバガバな実装でも良いと思うんだけど、客先じゃそんなこと言えない。
perlならdie "原因";とか。Javaならthrow new RuntimeException("原因", cause);とか。だめか？だめか。
辛い。まとまらない。つらい。
