質問: アプリケーションで想定するエラーやログのメッセージ管理はどのようなプラクティスがありますか? 例えば、データベースが切断された場合や、入力値が不正である場合など、 エラーの種類により、Exceptionクラスを定義するのか、 それとも、アプリケーション独自のExceptionクラスは1つで、 MessageIDなどで紐づけたCSVファイルのようなデータからメッセージを取り出すなど、 どのようなアプローチが一般的でしょうか。 エラーのカテゴリによって、エラーメッセージの粒度が違っていたり、 うまく体系化するのが難しいと感じています。
回答: **例外処理はオブジェクト指向**の仕組みです。 C言語になくて、C++やC#やJavaにあるというだけでなく、 じっさい、例外時に例外オブジェクトを生成するでしょう。 > > エラーの種類により、Exceptionクラスを定義するのか > > それとも、アプリケーション独自のExceptionクラスは1つ > > > だから、オブジェクト指向らしい例外処理ということでは、 例外の種類によって、例外クラスを分けていきます。 基本的には、普通のクラスを分けていくことと同じです。 ただ、小規模ならひとつで済む場合もあるかと思います。 というより、例外処理に手を掛けられないという方が実態かも。 > > エラーのカテゴリによって、エラーメッセージの粒度が違っていたり、 > > うまく体系化するのが難しいと感じています。 > > > たしかに、例外処理は難しいです。本に載ってないことが多いし、 そもそもエラーは個別的だから体系化が難しい。 じっさい、言語処理系のエラーメッセージですら、 分かりにくいことが多いですよね。 じゃあ、具体的にどうすればいいのかというと、 本体の処理ができた後でエラー処理をくっつけていくのではなく、 **最初から**エラー処理や**例外設計**がしやすい設計にします。 たとえば、**レイヤーアーキテクチャ**で階層を分けるのは、 理由は色々あるでしょうが、エラー処理のしやすさも、そのひとつでしょう。 というのも、**UIやDB**は独自のエラーをモリモリ出してくるから、 それらを**ドメイン**モデルと混ぜてしまうと、 エラー処理でドメインが埋まってしまう。だから分けると。 > > データベースが切断された場合や、入力値が不正である場合 > > > 何を例外にするかは、私の見方では大別すると、 エラー処理には、「**例外なく例外を使う**」考え方(統一派)と、 DBは例外で、入力値の不正は例外にしない、 という「**例外は例外的状況にのみ使う**」という考え方(純粋派)があります。 統一派は入力値の不正も例外にしますが、 純粋派はそれは「準正常系」だといって、例外にしません。 どうするかというと、IF文で分けたり、戻り値でエラーを表現したりします。 例外処理における統一派と純粋派は、それぞれ一長一短だと思います。 言語仕様を見ると、Javaは統一派で、C#は純粋派に近い立場でしょう。 統一派は、IF文のエラー処理で本体の処理が埋もれる、 リターン値のエラーコードは見過ごされる、と主張します。 純粋派は、とくに大規模では例外処理が複雑になり過ぎる、 だから実態としては例外でできることが少ない、と主張します。 「すべてがオブジェクト」みたいに「すべてのエラーが例外」と、 例外に統一化した方がOOの理想郷ではあるが(私も考え方としては好きです)、 現実には純粋主義的な例外の方が使いやすい場面もあるのかなと思います。