システム例外とアプリケーション例外の明確な説明
JPA仕様では、システム例外とアプリケーション例外が区別されています。線が正確にどこに描かれるかについて少し混乱しています。私の推測：
アプリケーション例外は、コードによって使用されるコードまたはライブラリが明示的または暗黙的にスローする例外です。
- これには、ソースに関係なく、すべての例外、ランタイム、チェックが含まれますか？
システム例外は、おそらく永続性プロバイダーによってスローされた例外です。確かにjavax.persistence.PersistenceExceptionのすべてのサブクラスが含まれています。
- プロバイダーコードによってスローされる他の例外についてはどうですか？
- 他のJava EEライブラリによってスローされた例外はどうですか？
- 例外が
EJBExceptionでラップされている場合、違いはありますか？
ApplicationException アノテーションを使用して動作にどのように影響を与えることができますか？まだ使われているのを見たことがありません。
アプリケーションエラーは、システムエラーではなくビジネスロジックエラーが発生した場合にスローされます。
重要な違いがあります：アプリケーションの例外によってトランザクションが自動的にロールバックされることはありません。クライアントは、アプリケーション例外がスローされた後に回復する機会があります。
アプリケーション例外は、EJBExceptionとして再パッケージ化されることなくクライアントに送信されます。したがって、これらを使用して検証エラーまたはビジネスロジックの問題を報告でき、クライアントに到達します。
これには、ソースに関係なく、すべての例外、ランタイム、チェックが含まれますか？
いいえ。デフォルトでは、アプリケーション例外は、RuntimeExceptionまたはRemoteExceptionを拡張しない例外です。以下で説明するように、これを変更できます。
ApplicationExceptionアノテーションを使用して動作に影響を与えるにはどうすればよいですか？
トランザクションを自動的にロールバックする場合は、@ ApplicationException（rollback = true）を使用できます。
EJBExceptionとしてラップすることを回避し、それらの自動ロールバック動作を定義するために、RuntimeExceptionおよびRemoteExceptionのサブクラスでアノテーションを使用することもできます。
他のJava EEライブラリによってスローされる例外はどうですか？
それらは同じルールに従いますが、XML記述子を使用して、サードパーティクラスをアプリケーションの例外として宣言できます（自動ロールバックの有無にかかわらず）。
プロバイダーコードによってスローされた他の例外についてはどうですか？
確かではありませんが、プロバイダーコードからシステムエラー以外のエラー（リモート例外またはランタイム例外）が発生することはほとんどありません。
例外がEJBExceptionでラップされている場合、違いはありますか？
はい。クライアントコードでの例外の処理方法に影響します。
（参照：Enterprise JavaBeans 3.0、Bill Burke、O'Reilly）
少しお役に立てば幸いです。
Mahesh DesaiがCoderanchに与えたこの非常に明確な説明を追加する必要があると思います。
Exceptionのサブクラスであるが、RuntimeExceptionおよびRemoteExceptionのサブクラスではない例外は、アプリケーション例外です。すべてのアプリケーション例外はチェック済み例外なので、アプリケーション例外をスローできるメソッドで別のメソッドを呼び出すときは、呼び出し側メソッドのthrows句で宣言するか、呼び出し側メソッドの本体でキャッチするか、またはその両方を行う必要があります。 。
RemoteExceptionsを除くすべてのシステム例外は、チェックされていない例外であり、ユーザーは処理できません。