2

3 タイヤ アーキテクチャのアプリケーションがあります。そして、このコンテキストで例外を処理する方法がわかりません。いくつかの質問を集めました：

1. のような一般的な例外を作成し、PersistentExceptionすべての DAO クラス メソッドが 1 つのタイプの例外のみをスローする ようにする必要がありPersistentExceptionますか? つまり、すべての DAO メソッド (CRUD) 内では、次のようにします。

  public create(Entity instance) {
       try {
        ...// all operations here
       } catch(Exception e) {
          throw new PersistentException(e);
       }
    }

2. すべての EJB サービスに対して 1 つの例外クラスを作成しても問題ありません (EJB インターフェースごとに 1 つの例外)。

つまり、対応するとインターフェースを持つPersonManagementBean、のような EJB Bean があるとします。それらはクライアントに公開されます。つまり、実際にはセッション ファサードです (したがって、サービス層に配置されます)。では、すべての Bean ( 、、 )に対応する Exception クラスを作成することをお勧めします。OrganizationManagementBeanEmployeeManagementBean@local@remotePersonManagementExceptionOrganizationManagementExceptionEmployeeManagementException

それとも、ServiceException(DAO の場合のように) 例外を 1 つだけ呼び出す方がよいでしょうか?

3. サービス (忙しさ) レベル (一般的なケース) をスローする可能性のある例外の種類は? DAO ( PersistentException) 例外をクライアントに伝播できますか? すなわち

public void relocatePerson() {
   try {
      Person p = personDao.getPerson(); // can throw PersistentException
      ....
      if (someCondition) {
         throw new PersonManagementException(); // throwing same PersonManagementException
      }
      ....
   } catch(PersonManagementException e) {
       throw e; //don't need to rewrap same exception
   } catch(PersistentException e) {
       throw e; // DO I need to throw it as PersistentException to client? Or it's better to rewrap it as  PersonManagementException?
   } catch(Exception e) {
       throw new PersonManagementException(e) //throwing all exception as service specific exception
   }

}

または、すべての例外 (一般的なケース) をサービス固有の例外として再スローする必要がありますか?

  • 「一般的なケース」とは、場合によっては、一部のメソッドがいくつかの役立つ情報 (たとえばValidationException、どのオブジェクトが検証規則を通過しないかに関する情報) を含む追加の例外をスローできることを知っていることを意味します。
4

2 に答える 2

0

はい、すべての DAO クラス メソッドで 1 つのタイプの例外のみをスローするようにする必要があります - PersistentException。あらゆる種類のDB関連の例外を1つのタイプにキャッチすると役立つ場合があるためです。さらに、パラメーター化されたコンストラクターを使用して PersistantException に設定するときに、特定の例外に関するメッセージを設定できます。i.e. throw new PersistentException("Exception while opening a connection",e);

2 番目の質問は、要件によって完全に異なります。異なるエラーを表示し、異なるエラー ページを表示し、それら (各 Bean のエラー) を個別に処理する場合は、Bean ごとに個別の例外クラスを作成する必要があります。

3 番目の質問ですが、私の見解では問題ありません。PersistentException を、DAO またはヘルパーが最初に呼び出されるレベル (つまり、ActionBean またはサーブレット) に伝播できます。そこでエラー メッセージを設定し、それらをアーキテクチャ レベルのハンドラー (通常は構成ファイルまたは xml ファイルで構成されます) にスローできます。

例外を扱うときは、「早く投げて遅くキャッチする」ことを忘れないでください

于 2013-01-18T13:54:59.307 に答える
0

失敗を通知する例外については、例外を1 つだけ使用します。理由: この場合、クライアントは何もできませんが、スタックトレースをログに記録したり、ユーザーにエラーを報告したりします。

リクエストを処理するための別のアプローチが必要であることを通知するためだけに、例外をスローする必要がある特別な状況がいくつかあります。これらの場合のみ、特定の例外が必要です。

リモート クライアントは、障害が発生したこと以外はほとんど知りたがりません。冗長な例外クラスでリモート インターフェイスに負担をかけないように十分注意してください。

于 2013-01-18T14:02:16.620 に答える