2023-05-25Organizationエラーをちゃんと分類しましょうという話sell設計,エラー処理エラー処理はいろんなパターンがあって、ケースバイケースとぶん投げられることも多いんですが、これ実は3種類に分類して考えるとかなりすっきりします。その3種類とはシステムの想定内のエラーシステムの想定外のエラーバグです。システムの想定内のエラーシステムの想定内のエラーとは例えば指定のIDのユーザーが見つからない必須の入力パラメータがないなどの事象です。これらはプログラムコード内ではエラークラスとして返されたり例外としてthrowされることもありますが、実際にはエラーではありません。これらはアプリケーションとしてその場合どうするか?をちゃんと規定してその通りに実装することが大切です。Webアプリケーションでは多くの場合40xのレスポンスを返すことになります。システムの想定外のエラーシステムの想定外のエラーとは例えばDBが落ちている外部のWebサービスとの通信エラーなどです。これらはアプリケーション開発者にはどうしようもできないことが多く、できることといえば運用者にすみやかに通知する仕組みを作るぐらいです。Webアプリケーションでは503を返すことが多いです。システムをもっと大きな視点から捉えた場合にはDBのダウンまで想定することもありますが、それはアプリケーションの外側の話なのでアプリケーション自体が意識する必要はほとんどありません。バグバグは文字通りアプリケーション開発者が仕込んでしまったバグです。どんなに優れたシステムであっても絶対にバグはありえるものと想定しておくことが大切です。バグはできるだけ早期に検知できることが大切です。if〜elseの分岐で最後のelseには絶対に来ることがないとわかっている場合はそこで例外を投げちゃいましょう。来るはずのないところに来たということはその前段階のどこかにバグがあります。そこを通してしまうとそれだけバグの検知が遅れることになります。assertやrequireを使うのも同様にバグの検知をできるだけ早くするためです。Webアプリケーションの場合は通常500エラーになります。(ほとんどのWebアプリケーションフレームワークは開発者の書くコードにバグがあることを想定しているので例外をキャッチした場合は500エラーになります。)同じエラーでも分類が違うことがあるここでは「ユーザー登録時にメールアドレスの登録をチェックする」という処理を考えてみます。色々な実装方法がありますが、ここではDBのUnique制約にひっかけてエラーをキャッチするという方法を取ったとします。この時に発生するUnique制約エラーはエラーではありません。システム内で想定されている挙動だからです。ここ以外の想定外の処理でUnique制約エラーが発生した場合はおそらくはバグ(もしくは仕様バグ)です。このように同じエラーであっても、その意味するところが全く別のものであることがあり得ます。ここで分類を考えずに目の前のエラーだけを見て「DBのUnique制約エラーはどう処理すれば良いだろう?」とか考えてしまうと迷路にハマることになります。まとめエラー処理でお悩みの人はわりとこの3つをごっちゃにして考えている人が多いです。システムの想定内、想定外のエラーを区別していないバグがありえることを想定していないまたは、その両方ここをちゃんと区別すると、かなりスッキリすることが多いです。目の前のエラーがどこに分類されるものであるかを考えてみましょう。ここをクリアにしてもそれでもなお悩ましいという人は多分本当に難しいんだと思うので頑張って悩んでください。