JPA Runtimeexceptions während Persistierung

[DerLudinator]

Hallo,

ich möchte gerne, dass eine EJB eine Modifikation an einem Datensatz durchführt und anschließend diese in die Datenbank schreibt / updatet. Jetzt stellt sich mir die Frage, wie ich das mit der Fehlerbehandlung mache.
Sollte ich die RuntimeExceptions, die bei einem entityManager.merge(foo) auftreten können, in checked Exceptions packen in diese dann weiter werfen, sodass mein JSF-Frontend auf diese regieren kann? Oder sollte ich diese Runtimeexceptions (wie es ja eigentlich sein sollte) nicht behandeln und einfach die unchecked Exceptions fliegen lassen?
Ich bin da leider etwas verwirrt und habe noch nicht sehr viel Erfahrung mit sowas, zumalen ich das hier nur als ein Hobby betreibe

Hier mal die Methode meiner statefull-EJB:

public void editUserPassword(final String oldPassword, final String newPassword) throws UserPasswordWrongException{
        Benutzer currentUser = getCurrentUser();
        //Hashen
        final String newPasswordHash = PasswortUtil.getSHA256(newPassword);
        
        //Hashen
        final String oldPasswordHash = PasswortUtil.getSHA256(oldPassword);
        
        if(oldPasswordHash.equals(currentUser.getPasswort())){
            currentUser.setPasswort(newPasswordHash);
        }else{
            throw new UserPasswordWrongException("User (" + currentUser.getBenutzername() + ") hat beim Versuch, sein Passwort zu ändern, ein falsches, altes Passwort eingegeben");
        }
        
        //Speichern (em ist ein per @PersistenceContext injiziierter EntityManager
        em.merge(currentUser);
    }

In a nutshell: Lieber checked-Exceptions werfen und das FrontEnd dazu zwingen, auf den Fehler mit einem try-catch zu reagieren, oder lieber das FrontEnd mit RuntimeExceptions "bewerfen" und evtl. im Falle von JSF mit ExceptionHandlern bzw. Einträgen in der web.xml arbeiten?

Ich danke schonmal für alle, die mir Tipps geben können
P.s.: Erst zu Weihnachten bekomme ich mein erstes EJB-Buch, wie gesagt: Ist ein Hobby (das ich aber sehr ernst nehme)

 

[FArt]

So handeln, wie immer...

Kann der Caller auf diesen Fehler sinnvoll reagieren? Dann ist eine checked Exception (oder eine dokumentierte, behandelbare spezielle RuntimeException) wohl die richtige.

Immer das Design im Auge behalten bzgl. Kapselung (z.B. Law of Demeter berücksichtigen). Niemand will in der höheren Businesslogik eine Exception aus der Persistenzschicht behandeln wollen.

Einziger Unterschied im EE Umfeld: berücksichtige, dass im Falle einer checked Exception und CMT die Transakion per Default nicht zurückgerollt wird. Bei RuntimeExceptions wird die Transaktion grundsätzlich zurückgerollt.

 

[DerLudinator]

Hallo und danke schonmal fuer die Antwort

Ich habe schon immer Probleme mit den Exceptions
Mein FrontEnd, dass in diesem Fall der Caller ist, kann ja im Prinzip darauf reagieren, indem es dem Benutzer sagt: Da lief was falsch, probiers nochmal.
Also sollte ich zum Beispiel eine EntityExistsException der Persistenzschicht in eine checked wandeln, die dem Frontend dann sagt, dass dieser Datensatz schon existiert und der Benutzer einen anderen erstellen soll?
Sorry, ich bin da noch nicht so ganz durchgestiegen

 

[tfa]

Auf Checked Exceptions würde ich generell verzichten. Auf RuntimeExceptions kannst du genau so reagieren wie auf Checked Exceptions - niemand hindert dich. Die allermeisten Exceptions, die in der Persistenzschicht auftreten können, sind sowieso nicht behebbar.

 

[FArt]

Auf Checked Exceptions würde ich generell verzichten. Auf RuntimeExceptions kannst du genau so reagieren wie auf Checked Exceptions - niemand hindert dich. Die allermeisten Exceptions, die in der Persistenzschicht auftreten können, sind sowieso nicht behebbar.

Ist eine philisophische Frage.. die einen sagen so, die anderen so. Hat eben auch seine Nachteile.

Auf jeden Fall ist das CMT Verhalten der EJB in seinem Fall anders, was explizit berücksichtigt werden muss!!!!

 

[tfa]

Ist eine philisophische Frage.

Eigentlich nicht. Kann sein, dass man bei EJB einen Workaround braucht (ich habe gerade so ein Problem mit Webservices und Checked Exceptions), aber philisophiert wurde über das Thema schon genug. Die Erkenntnisse haben sich vielleicht noch nicht so rumgesprochen.