Une explication claire de l'exception du système par rapport à l'exception de l'application
La spécification JPA fait la différence entre les exceptions système et les exceptions d'application. Je suis un peu confus quant à l'endroit où la ligne est tracée exactement. Mon estimation:
Une exception d'application est une exception que votre code ou vos bibliothèques utilisent par votre code, de manière explicite ou implicite.
- Est-ce que cela inclut toutes les exceptions, le temps d'exécution et la vérification quelle que soit la source?
Une exception système est probablement une exception levée par le fournisseur de persistance. Il contient certainement toutes les sous-classes de javax.persistence.PersistenceException.
- Qu'en est-il des autres exceptions levées par le code du fournisseur?
- Qu'en est-il des exceptions levées par d'autres bibliothèques Java EE?
- Cela fait-il une différence si l'exception est enveloppée dans un
EJBException?
Comment puis-je influencer le comportement en utilisant l'annotation ApplicationException ? Je ne l'ai encore jamais vu utilisé.
Une exception d'application doit être levée en cas d'erreur de logique métier, par opposition à une erreur système.
Il existe une différence importante: les exceptions d'application n'entraînent pas automatiquement l'annulation d'une transaction. Le client a la possibilité de récupérer après la levée d'une exception d'application.
Les exceptions d'application sont envoyées au client sans être reconditionnées en tant qu'exception EJBException. Par conséquent, vous pouvez les utiliser pour signaler des erreurs de validation ou des problèmes de logique métier, et ils atteindront le client.
Est-ce que cela inclut toutes les exceptions, le temps d'exécution et la vérification quelle que soit la source?
Non. Par défaut, les exceptions d'application sont les exceptions qui ne prolongent pas RuntimeException ou RemoteException. Vous pouvez changer cela, comme décrit ci-dessous.
Comment puis-je influencer le comportement en utilisant l'annotation ApplicationException?
Vous pouvez utiliser @ApplicationException (rollback = true) si vous souhaitez que la transaction soit annulée automatiquement.
Vous pouvez également utiliser l'annotation sur les sous-classes de RuntimeException et RemoteException, afin d'éviter l'encapsulation en tant qu'exceptions EJB et de définir leur comportement de restauration automatique.
Qu'en est-il des exceptions levées par d'autres bibliothèques Java EE?
Ils suivront les mêmes règles, mais vous pouvez utiliser le descripteur XML pour déclarer des classes tierces comme exceptions d'application (avec ou sans restauration automatique).
Qu'en est-il des autres exceptions levées par le code du fournisseur?
Je ne suis pas sûr, je pense que vous verriez rarement une erreur non système (exceptions à distance ou d'exécution) provenant du code du fournisseur.
Cela fait-il une différence si l'exception est encapsulée dans une exception EJBException?
Oui. Cela affectera la façon dont vous gérez les exceptions dans le code client.
(Réf: Enterprise JavaBeans 3.0, Bill Burke, O'Reilly)
J'espère que ça aide un peu.
Je pense, je dois ajouter cette description très claire, que Mahesh Desai a donnée sur Coderanch:
Toute exception qui est une sous-classe d'Exception, mais pas une sous-classe de RuntimeException et RemoteException, est une exception d'application. Toutes les exceptions d'application sont des exceptions vérifiées. Ainsi, lorsque nous appelons une autre méthode de notre méthode qui peut lever une exception d'application, nous devons soit la déclarer dans la clause throws de la méthode appelante, soit l'attraper dans le corps de la méthode appelante ou les deux. .
Toutes les exceptions système sont des exceptions non vérifiées, sauf RemoteExceptions et elles ne peuvent pas être gérées par l'utilisateur.