13

EJB仕様からの引用：

Beanメソッドでシステム例外またはエラーが発生した場合は、Beanメソッドからコンテナにエラーを伝播するだけです（つまり、Beanメソッドは例外をキャッチする必要はありません）。

しかし、私はそれを理解していません。すべての種類の例外をキャッチして（つまり、クラスをキャッチしようExceptionとして）、アプリケーションの例外として再スローするべきではないということですか？

より明確にするための例：

public void beanMethod throws MyApplicationException {
  try {
    // do something
  } catch (Exception e) {
     throw new MyApplicationException(e); // Should I do it like this? 
  }
}

または、これはEJB開発者ではなく、EJBリファレンス実装開発者（コンテナ開発者）のみです。後者の場合、結果として、コンテナはシステム例外をビジネスメソッドに伝播してはならず、catch(Exception e)ブロックがシステム例外をキャッチすることはありません。 ？

4

2 に答える 2

16

より多くの種類の例外があります：

  • システム例外（RuntimeExceptionsなど：NullPointerException）
  • ビジネス例外（独自の例外、例外を拡張しますが、RuntimeExceptionは拡張しません。例：NotEnoughMoneyOnYourAccountException）
  • エラー（例：OutOfMemoryError）

通常、ビジネス例外をキャッチする必要があります。ただし、もちろん、クライアント側で処理したい場合は、クライアント側にスローすることができます。デフォルトでは、BusinessExceptionをスローした場合、EJBコンテナはトランザクションをロールバックしませんが、次の方法で例外に注釈を付けることでこの動作を変更できます。

@ApplicationException(rollback = true)
public class NotEnoughMoneyOnYourAccountException extends Exception {

プログラムがRuntimeExceptionをスローすると、RemoteExceptionとしてラップされたクライアントに送信され、トランザクションがロールバックされます。これらはビジネス例外よりも例外が少ないため、通常、EJB側ではキャッチしません。

エラーはほとんど例外ではなく、JVMをシャットダウンすることさえできます。通常、プログラムでエラーを処理できないため、通常はエラーをキャッチしません。

于 2013-01-18T22:20:35.613 に答える
0

このヒントをどこから取得したのか、コンテキストは何かはわかりませんが、Beanメソッド自体は例外処理をまったく行わず、取得したものをすべてスローする必要があることを意味しているようです。throwsこの動作は通常、現在の句への変数入力など、環境/ランダムな要因に応じてメソッド本体がスローする可能性のある例外を追加することで最もよく実現されますMyApplicationException。

メソッド内のコードエラー（メソッド呼び出しではない）によって直接引き起こされる例外は、テストとデバッグを通じて取り除く必要があるため、通常は適切に処理する必要はありません。

于 2013-01-18T22:07:47.247 に答える