Commencez par relire le cours sur les EJB, section "Exceptions dans les EJB".
C'est une exception d'application car elle est liée à une règle de gestion de l'application et elle peut être attrapée et prise en compte pour le fonctionnement de l'application.
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 de l'EJB 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 l'EJB. 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 système (un exception d'application comme CompteException ne provoquerait pas de rollback). Vous pouvez choisir celle que vous voulez mais l'exception EJBTransactionRolledbackException semble convenir parfaitement. 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. Vous pouvez aussi lier le CompteException à cette nouvelle exception (revoyez votre cours sur les exceptions si vous ne savez pas comment faire).
Remarque : 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 dans les EJB) et il n'est pas possible de lancer explicitement un rollback.
Il faudra évidemment attraper cette exception système dans les backing beans pour afficher un message d'erreur à l'utilisateur. Dans la correction c'est cette solution qui est écrite pour le transfert sans Ajax.
Remarque : Pendant l'exécution, vous verrez que l'exception système 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 Java EE l'impose.
On ne vous demande pas de modifier le transfert avec Ajax pour utiliser l'exception. Elle utilise une autre stratégie : les conditions de validation (en particulier un solde suffisant) sont testées dans la méthode "action" du backing bean avant d'appeler la méthode de l'EJB.