4

3 つのモジュールに分割された Java プロジェクトがあります。これら 3 つのモジュールは個別の Maven プロジェクトですが、それらの間には依存関係があります。関係は単純です。

モジュール A はモジュール B に依存します

モジュール B はモジュール C に依存します

  • モジュール C は、セッションの作成などの低レベルのデータベース タスクを処理するライブラリです。
  • モジュール B は、DAO、DTO、エンティティなどを定義するデータベース ライブラリです。
  • モジュール A は、ビジネス ロジックを含む RESTful Web サービスであり、ライブラリ B を使用して DB にアクセスします。

パブリック メソッドによってスローされるモジュール C で定義されたチェック済み例外があります。モジュール B は、この例外を取得できます。

私の質問は、B が

  1. このチェック済み例外をキャッチし、モジュール B でローカルに定義された別のチェック済み例外をモジュール A にスローします。
  2. チェックされた例外をキャッチするのではなく、パブリック メソッドでこの例外を宣言して、モジュール A に渡されるようにします。

私の個人的な意見では、Java の事前定義された例外でない限り、モジュールはクライアント モジュールに対して定義したチェック済み例外のみをスローする必要があります。しかし、これには確かに欠点があります。つまり、同じエラー状態を表すために、複数のモジュールで 2 つの異なる例外を作成する必要があります。

誰でもあなたの意見を共有できますか？

4

2 に答える 2

2

例外をスローすることよりも、それらを処理することについて心配する必要があります。

例外は例外的であるべきです。適切に処理された場合にのみ捕獲する必要があります。処理できない場合は、未チェックの例外であれば何もせず、そうであればキャッチして再スローします。

一部のモジュールは、決して例外をスローしてはなりません。スタック トレースが表示されると、ユーザーのエクスペリエンスが低下するため、UI コントローラーを考えています。HTTP は例外を認識していないため、Web サービスについても考えています。

エラー処理戦略は、例外を中心に展開するべきではありません。モジュール間でコードを送信し、それらを処理する契約を結ぶことができます。

ロギングは処理されていません。

あなたが投稿した内容に基づいて何をすべきかについてアドバイスすることはできませんでした。モジュールが何をしているかについてもっと知りたいです。

于 2013-09-01T14:29:40.023 に答える
2

これを型結合の観点から見ていきます。モジュール B がモジュール A からモジュール C の型を完全にカプセル化する場合、例外のためだけに A と C の間に型結合を導入しないでください。モジュール B が既に C の型を A に公開している場合 (つまり、A が B への依存関係を介してだけでなく、C に直接依存している場合) は、先に進んで C の例外をスローします。

于 2013-09-01T14:33:57.050 に答える