Spring sterowanie logiką w przypadku błędu - jak obsługiwać? Wyjątki czy zwracać samemu informacje o błędach?

Hej, robiłem sobie aplikacje w Springu do nauki, dużo się naczytałem że lepiej nie stosować wyjątków do obsługi błędów (no nie do końca "błędów" - mam na myśli sytuacje, gdy w sklepie np. nie można utworzyć zamówienia, bo brak produktu. Albo próbę dodania nowego albumu do zespołu, który nie istnieje) no wyjątki są do sytuacji wyjątkowych. Robiłem Either<Błąd, Obiekt> jak znalazłem w kilku miejscach na - stacku, tutaj itd.

Widziałem też sporo kodu z waleniem wyjątku na mordę i obsługiwaniem go w handlerze i zwracaniem tam wiadomości wyjątku. Widziałem też sporo kodu z waleniem wyjątku i tylko zwracaniem statusu. Niby w wielu miejscach ludzie twierdzą, że tak się nie powinno robić.

Tymczasem mój wykładowca doktor inżynier Waldemar Korłub napier*ala wyjątkami i adnotacjami gdzie popadnie. W przykładach miał prostą logikę biznesować w kontrolerach.
Przykład z jego prezentacji:

Ogólnie sporo ludzi na labach nic nie kuma i tylko zwala od reszty (robią byle apka działała i oddają, często bez sensu), ja sobię w miarę radzę bo czytałem sporo i sam pisałem, to rozumiem co tam się dzieje. Bez własnej wiedzy też bym nic z tego nie rozumiał.
Raz mnie pan doktor skrytykował na labach, że tak mam płytką strukturę wyjątków, bo zrobiłem tak jak on że od razu dziedziczenie po RuntimeException. WTF?? Sam tak robi, a jak ja naśladuję to źle.

Już sam nie wiem jak się powinno pisać kod:

1. Stosować te wyjątki czy walić Either?
2. Używanie Either powoduje u mnie więcej kodu w serwisach, ale nie potrzeba żadnego handlera do wyjątków. Przy bardzo rozbudowanych metodach mam sporo kodu z tworzeniem/obsługą tych Eitherów. Robię coś źle?
3. Na wiosnę idę do pracy jako Junior Java Dev, jakiego podejścia używa się częściej w branży? Pewnie tego z wyjątkami, bo w sumie szybciej

Tymczasem mój wykładowca doktor inżynier Waldemar Korłub napier*ala wyjątkami i adnotacjami gdzie popadnie.

Robi tak jak mainstream. Mimo, że jestem przeciwnikiem takiego podejścia to akurat nie uważam, że to coś strasznego. Takie czasy.

1. Stosować te wyjątki czy walić Either?

Depends. Najprostsza reguła - jeśli wyjątek da się sensownie obsłużyć to Either (a kiedyś Checked Exception). RuntimeException jeśli nie da się obsłużyć, lub nie chcesz obsługiwać (to jest po prostu decyzja projektowa, że danego problemu nie obsługujesz).

2. Java trochę taka jest - ale upewnij się, że stosujesz flatMap, map, getOrElseGet i tym podobne.

3. IMO nadal adnotacyjnego/ wyjątkowego - ale to nie znaczy, że musisz to akceptować. Jak Ci karzą tak pisać to trudno, jako Junior dużo nie podskoczysz, ale cierpliwości - rok/dwa i możesz być bezczelny. Co do tego, że z wyjątkami jest szybciej - to różnie. Łatwiej popełnić błąd, przez który cały ten oszczędzony czas się wielokrotnie odbije czkawką.

1. Podany przykład jest bardzo szczególny bo @Transactional akurat steruje się za pomocą wyjątków. Jeśli chcesz sie tego pozbyć to musiałbyś użyć np. Springowego TransactionTemplate który daje ci bardziej "funkcyjne" api do transakcji
2. To jest trochę kwestia utrzymania spójnego "stylu". Albo robimy wszystko za pomocą Optional/Either/Try albo robimy za pomocą wyjątków. Mieszanie tych podejść to największa kupa.
3. Nie bardzo rozumiem czemu niby użycie Eitherów daje ci więcej kodu. Niby gdzie jest to powiększenie? o_O
4. Na hello worldach nie wszystko widać. Weź pod uwagę że w prawdziwym zyciu nie wystarczy rzucić runtime exception który wywali aż do kontrolera i zwróci użytkownikowi błąd. W rzeczywistości dla wielu problemów potrzebujesz mieć jakiś fallback, moze np. jakiś cleanup czy rollback trzeba wykonać, albo jakieś retry. I nagle sie okazuje że kod ci puchnie dwukrotnie bo wszędzie masz try..catch. Dodatkowo wyjątki bardzo słabo się komponują z takimi rzeczami jak Stream, CompletableFuture czy inne użyteczne mechanizmy.

Możesz wskazac, w którym miejsu slajdu masz napisane, żeby używać wyjatkow? Z tego, co widze, to jest slajd o rollbackowaniu transakcji w Springu. To nie ta lekcja.

Problem z Eitherami jest taki, że nie są elementem języka, więc wyjatki są standardem. Patologicznym standardem, ale jednak będą się zawsze przewijać, szczególnie w kodzie na wykładach.