例外クラスの場所を構造化するための一般的な、またはベスト プラクティスは何ですか?
パッケージ/名前空間myproject.person(個人用のモデルと DAO) とmyproject.order(注文用のモデルと DAO) と例外PersonExceptionとがあるとしOrderExceptionます。対応するパッケージに例外を配置する必要がありますか、それとも例外用の別のパッケージ (例: myproject.exceptions) に配置する必要がありますか?
最初のアプローチはより合理的です (機能によってソートされているため)。しかし、両方に関連する例外をどこに置くべきかという疑問が生じますか? 例えばConstraintViolationException
私の経験では、その例外に意味のあるパッケージに例外を入れるのが最善です。例外専用の特別なパッケージは作成しません。例外は、それらを使用するクラスの近くに存在する必要があります。
Javaクラスライブラリが行うことを実行します。例外を、それらをスローするAPIクラスおよびインターフェースと同じパッケージに入れます。
対応するクラスと同じ名前空間にそれらを配置します。より一般的な例外タイプについては、それらを使用するクラスをカバーする最も具体的な名前空間にそれらを配置するようにしてください。そのため、ConstraintViolationExceptionはmyproject名前空間に配置されます。
各アセンブリに独自の操作があり、多くの種類の例外（PersonExceptionまたはOrderExceptionだけでなく、PersonInvalidDataExceptionまたはPersonDataPersistException）があるとします。 これらの例外は、たとえば、ログに記録して電子メールを送信するBaseExceptionを実装できます。
したがって、（私の意見では）より手頃な方法は、名前空間でそれらを分離することです。
例外が1つのクラスまたはクラスの機能グループのみに使用される場合は、それらの近くに置きます。Exception がアプリケーション jr ライブラリに対して共通の意味を持つ場合は、それをその oun 名前空間に配置します。私見では
私がこの考え全体で抱えている問題は、例外は一般に、何がうまくいかないかについての手がかりを与えずに展開している災害に関係するオブジェクトを参照しているように見えるNullPointerExceptionのに対し、例外は何がうまくいかないかの線に沿って設計する必要があるということです。PersonExceptionPerson オブジェクトが例外の原因でしたか? Person に内部ロジックの問題があるためですか、それともそのメソッドの 1 つに不適切な引数が指定されたためですか? または、データベースで Person が見つからないために例外が発生しましたか?
両方のオブジェクトに関連する例外についてあなたが 2 つの考えを持っているという事実は、私の懸念を強めるだけです。例外 (EntityNotFoundException、BadArgumentException、MinorCannotOrderPornException) の設計を再考することをお勧めします。ジレンマに対する答えがより明確になることを願っています。
すべての例外をプロジェクトの名前空間 (つまり、myproject) に保持するだけです。クラスごとに 1 つのファイルを作成すると、プロジェクト ビューのスペースを占有する可能性があるため、通常はファイル (exceptions).cs を呼び出して上部に表示し、すべての例外を 1 か所に配置します。
大規模なプロジェクトの場合、通常、アセンブリをさまざまな名前空間に分割すると、各名前空間に独自の例外セットが与えられますが、アセンブリごとに 100 を超えるクラスについて話していることになります。