データベースレイヤーにおける例外処理の設計パターン

Question

私のシステムは、サービスレイヤーとデータベースアクセスレイヤーの2つのメインレイヤーを持っています。

私は、データベース操作のためのサービスレイヤへのインターフェイスを公開しています。

さて、このインタフェースでは例えばDAO層のすべての操作によってスロー得ることができますいくつかの例外があり、タイムアウト例外は

は、明示的にすべてのために指定する以外のこの仕様を表現する方法がありますetc-方法はthrows ExceptionName？

Answer 1

ここには複数のオプションがあります。

• あなたがチェック例外を使用する場合は、いくつかの抽象ベースの例外を作成して置く：しかし、私は私の「意見」は何とかあなたが今では多くの場所で見つける「ベストプラクティス」をアップ一致する考えるあなたのスローリストにその1つ。 本当にあなたのスローリストに2つ以上の例外は必要ありません。単にそのような大量のスローリストが時間の経過と共に成長し、すぐに彼らがすべての層を汚染するです。
• チェック例外を使用しないこともできます。代わりに、適切なランタイム例外をスローし、その事実をjavadoc経由でインタフェースに文書化します。多くの人々は、チェックされた例外とチェックされていない例外との間の "戦争"は、を超えてであり、は、が無効であると主張する。とにかく上に何か「一般的なものをすべて捕まえる」必要があるからです。だから、そのコードがとにかく書かれるとき、なぜそのようなメンテナンス集約的なスローのリストでハッスルと喧騒？！

Answer 2

throws ExceptionNameを持つすべてのメソッドに明示的に指定する以外に、この仕様を表現する方法はありますか？

ありません。ごめんなさい。

階層としてカスタム例外を（再）実装することにより、定型文の量を潜在的に減らすことができます。しかし、あなたの例外がチェックされないようにしたい場合を除き、、その後いくつかの定型文が必要です。

---

^{1 - それには欠点もあります。チェックを外すと、処理されない例外のコンパイル時間チェックが失われます。}