2020-10-18

例外処理は例外が発生する可能性がある場所であれば常にするべきなのか

背景

Vue/JavaScriptで開発している際に、通信レスポンスが想定している型と異なっており、配列を想定している箇所が空の際に空配列でなくnullを返す結果、 null.map みたいなことをしようとしてしまってランタイムエラーが発生する。みたいなことが頻発した。

で、その時に、それに対する例外処理をしていない事に対して。

人間は完璧なコードを書けない。書いた関数の中でミスをして例外を発生させることは全然あるし、それはしょうがない。ただ、例外処理をしていないコードは人間が完璧であることを前提にした脆弱なコードだ。例外処理をしていないなんて考えられない。そこはちゃんとしよう。

という話が出たことがあった。当時は例外処理に関して正直深く考えたことが無かったので何も言えなかったんだけど、改めて本件に関して考えたことをまとめておきたい。

要約

• 開発者の実装ミスによる例外まで想定していたら時間がいくらあっても足りない
• そもそも、例外処理より例外を発生させないことを優先すべき

開発者の実装ミスによる例外まで想定していたら時間がいくらあっても足りない

例外処理を作り込むのは当然工数とのトレードオフ。作っているアプリケーションにどこまでの堅牢さが求められるのかによってそこは適宜どこまでやるのか判断すべきかと思う。

例外処理対応をするのは基本高コストと思っている。「ここで例外が発生した場合はどのような対処をすべきなのか」というのを状況によって考えないといけないので。

で、フロントエンドに関してはそこまでの堅牢さは必要ではないと思っている。何かしらの例外が発生したとしても、それが即大損害に繋がるというようなケースは少ない。もちろん大損害に繋がるケースもあるかもしれないが、そのようなケースは例外的だと思うので基本的には開発者の実装ミスによる例外は投げっぱなしで良いと思う。もちろんSentry等エラー検知の仕組みは必須だけど。

そもそも、例外処理より実装ミスによる例外を発生させないことをまず優先すべき

例えば、今回のケースは根本的な問題として想定しているレスポンスをバックエンドが返していないことにある。これに対していくらフロントエンド側で例外処理をしようが、アプリケーションが正常に動作しないことには変わりがない。

そんなところに工数をかけるより、バックエンドが返すレスポンスを再調査することに時間をかけるべきだった。もしくはフロントエンドでレスポンスを処理する際にzodでparseして、想定外の型であれば早期に検知出来るようにするのも良かったかも知れない。（レスポンスの型が異なることによるランタイムエラーが頻発し、その調査に時間がかかっていたためそれの短縮が見込める）