Metody void to świnie. Każda kryje jakieś ryzyko błędu, ale niestety nie jest ich łatwo uniknąć (często nie warto).
Jeśli zwracasz void to w zasadzie zabawa w Either czy Optional nie ma sensu, i tak nikt wyniku nie sprawdzi, podobnie jak to będzie boolean.
Optionale, Eithery czy nawet boolean działają jak wywołujący metodę musi jakoś skorzystać z wyniku. Tu sztucznie wrzucony Either będzie pewnie olany.
Dlatego: Exception to dobre rozwiązanie w tym przypadku, (jeśli chcemy jakoś zmusić do obsługi).
Jest natomiast więcej problemów... bo void to świnia i ten kod ma problemy.
Jeśli będzie więcej wątków( bo to jakiś serwer) lub więcej programów podłączonych do bazy danych to nie zadziała zabezpieczenie.
**check **i **delete **są w osobnych transakcjach. Sprawdzenie powinno być w jednej sesji/trransakcji inaczej obiekt może być usunięty w innym wątku tuż po sprawdzeniu. Kupa.
Co więcej nawet jak będzie w jednej sesji... to połączenie/baza musi spełniać poziom izolacji REPEATABLE READ, żeby faktycznie zabezpieczenie z check działało.
Co więcej - kasowanie z bazy deletem to często słaby pomysł ogólnie. W projektach biznesowych się tego raczej unika (po iluś latach człowiek uczy się, że UPDATE też się unika, ale to kolejny poziom).
Jak to w ogóle zrobić dobrze?
Generalnie jeśli zależy nam na tym, żeby nie dało się skasować oibiektu, którego nie ma w bazie... to wystarczy, że ten obiekt będzie parametrem metody **delete **, drugim parametrem metody będzie sesja!
Sprawdzanie dodatkowo trzeba zrobić w tej samej sesji/transakcji więc albo przekaż session do metody check, albo... skorzystaj z session.delete(String quyery)
, w tym drugim przypadku możesz sprawdzić ILE faktycznie obiektów skasowano!
To praktycznie wystarczy. Jeśli to jest zwykła Encja hibernatowa, to ktoś albo ją wyciągnie z bazy danych (w tej samej sesji) i poda do delete (wtedy wiadomo, że obiekt istniał i git)Albo ktoś złośliwie utworzy *ręcznie *i poda do delete, wtedy na złośliwość można po prostu odpowiedzieć RuntimeException -bo to bardzo nietypowa sytuacja, błąd programisty.
Można pójść nawet dalej i parametrem metody utworzyć obiekt, który NA PEWNO zostął właśnie wyciągnięty z bazy danych i nie da się go inaczej stworzyć. (Zrobić wrapper na entity). Ale to raczej ostrożność potrzebna przy dużych projektach zespołowych.