エラーハンドリング

エラーが発生した時の処理のことです。
この処理の特徴は、正常に動作している限りは使われないということです。

開発していると色々細かくエラーハンドリングしたくなりますが、ここでの開発生産性Tipsは

【必要最低限のエラーのみハンドリングする】

です。

保守すべきコードが増えれば増えるほど保守コストが高くなっていきます。
そのため、できる限りコードを増やさないことが開発生産性を高く保つコツです。

そこで今回はエラーハンドリングに着目しました。

エラーハンドリングは前述した通り、正常に動作している場合は使われません。
言い換えると実装しなかったとしても正常動作には影響を及ぼさないということです。
そのため、必要最低限のエラーハンドリングだけ実装すべきです。

必要最低限のエラーハンドリングとは？

ほとんどの場合、エラーハンドリングはグローバルな処理でガバッと実装していることが多いと思います。
例えば、APIであればエラーが発生したらBadRequestを返却するようにしていたり、クライアントではエラーが発生したら特定のアラートなどを表示するようにしていると思います。

基本的にはそれだけ十分だと思います。
グローバルなエラーハンドリングだけで済む場合、実装は共通化された1箇所だけで良いし、個々にエラーハンドリングを実装する必要もなくなり、大幅に実装や保守のコストが削減されます。

とは言っても開発していると、個別でエラーハンドリングしたくなることがあります。
その時の判断基準としては、このエラーハンドリングがなかったら本番運用中に利用者がどれくらい困るか？で考えると良いと思います。

例えば、下記のような場合は個別でエラーハンドリグすることを検討した方が良いと思います。

エラー発生か確率が高く、ユーザーにエラー原因が伝わることでエラーからリカバリできる(エラー原因を伝えないとできない可能性が高い)
- ただし、そもそもエラー発生確率を減らす方法があるならそちらを検討すべき
エラーが発生した場合、リトライなどでの回避が難しく高確率で問い合わせや離脱につながる

一方で下記のようなものは対応不要だと思います。

プロジェクトを継続的に運用している開発チームであれば、下記の問だけで判断可能だと思います。

「エラーハンドリングの実装が漏れてしまい、本番環境で当該エラーが発生しました。hotfixや差込対応で数日以内に修正しますか？」

数日以内に差し込み作業として修正するレベルなら最初から入れておくべきだし、それ以外なら実装しなくて良いと思います。

実装していると、自分のコードはキレイに、そして完璧に作りたくなるものです。
ただ、ほぼ発生しないエラーハンドリングなどレアケースな処理を実装してしまうと、運用では1回も動いたことがないのに保守し続けていくコードが発生することになります。

このようなコードが積もり積もって運用コストを上げていくので、必要最低限のコードだけ実装するということを心がけるようにしましょう。