Commencez par relire le cours CDI, section "Transactions et exceptions".
Elle ne doit pas être une exception "runtime" qui provoquerait automatiquement un rollback de la transaction en cours. En effet, suivant les règles de gestion de la banque, cette exception pourrait être attrapée et prise en compte pour le fonctionnement de l'application. Par exemple, une règle de gestion pourrait accepter les retraits supérieurs au solde, et faire payer des agios au client qui possède le compte en banque.
Ecrivez une classe simple qui hérite directement de Exception (pas de RuntimeException).
Modifiez la méthode qui retire de l'argent sur un compte pour tenir compte de la nouvelle règle de gestion. Est-ce que cette méthode peut réparer le problème (en ce cas elle attrape l'erreur) ou est-ce qu'elle laisse l'exception se propager ? Pour notre cas, l'erreur ne peut pas être réparée et on laisse donc l'exception se propager.
Si l'exception se propage, il faut aussi modifier les méthodes qui utilisent cette méthode (la méthode du bean CDI qui retire de l'argent à un compte et celle qui transfert de l'argent entre 2 comptes). Jusqu'où faut-il laisser remonter l'exception ? Le plus souvent on la laisse se propager jusqu'à la méthode du backing bean qui a lancé l'opération. Dans cette méthode on attrape l'exception et on affiche un message d'erreur pour que l'utilisateur sache qu'il y a eu un problème.
Modifiez donc le code des backing bean concernés (pour le transfert d'argent et les mouvements sur un compte) et de l'EJB qui gère les comptes.
L'exception CompteException remonte donc dans le bean CDI. Puisqu'il ne peut pas réparer l'erreur, celui-ci doit s'assurer que la transaction se terminera par un rollback.
Le plus simple est de lui faire lancer une exception runtime (un exception contrôlée par le compilateur comme CompteException ne provoquerait pas de rollback). Vous pouvez choisir l'exception runtime que vous voulez. Pour cela, il faut attraper l'exception CompteException et relancer la nouvelle exception. Pour le message attaché à cette nouvelle exception, reprenez le message attaché à CompteException. Il faut aussi lier le CompteException à cette nouvelle exception, comme cause première de l'exception (revoyez votre cours sur les exceptions en Java si vous ne savez pas comment faire).
Rappel du cours : Les exceptions d'application ne lancent pas automatiquement un rollback pour permettre au code de réparer éventuellement le problème. Par exemple, ici, le code pourrait permettre le retrait en facturant des frais à l'utilisateur. Dans votre code les transactions sont gérées par le container (voir cours sur les transactions) et il n'est pas possible de lancer explicitement un rollback.
Vous avez sans doute validé le solde du compte auquel on retire de l'argent dans les méthodes actions des backing beans. En ce cas, pour tester l'utilisation de l'exception, enlevez cette validation dans le backing bean utilisé pour le transfert entre 2 comptes.
Il faudra évidemment attraper l'exception runtime lancée par le bean CDI dans le backing bean pour afficher un message d'erreur à l'utilisateur.
Remarque : Pendant l'exécution, vous verrez que l'exception runtime a été enregistrée dans les logs du serveur d'application, même si elle a été attrapée par le code. La spécification Jakarta EE l'impose.