Spring REST i wyjątki- dobre praktyki

Cześć,

Rozwijam sobie aplikacje w celach edukacyjnych, zatrzymałem się na etapie rzucania wyjątków, ogólnie w aplikacji mam zdefiniowaną klasę ApplicationException, która dziedziczy po wyjątku RuntimeException no i w sumie to jest coś do czego wrzucam wszystkie błędy i kiedy zdarzy się coś złego wyrzucam ten błąd tylko z różną treścią wiadomości np. "Resource not found", "Username already exist" itd. Moje pytanie jest następujące- czy w przypadku niewielkiej aplikacji(powiedzmy do 50 klas) jest to dobre podejście aby rzucać jeden wyjątek i do niego pchać tylko różne treści wiadomości, czy lepiej zrobić kilka wyjątków, które będą obsługiwać konkretne przypadki tj. ResourceNotForundException, ResourceAlreadyExistException itd... ?

Różne wyjątki (osobne klasy) dla różnych kodów odpowiedzi.
Pamiętam że teraz pewnie mapujesz wszystko na HTTP 500 ale możesz mieć

ResourceNotFoundException.java które mapujesz na 404
ForbiddenException.java które mapujesz na 403
SuperDuperException.java które mapujesz na 500

Przykładowa implementacja w Jersey https://howtodoinjava.com/jersey/jax-rs-jersey-custom-exceptions-handling-with-exceptionmapper/

Powinny być klasy takie jak NotFoundException mapowane na 404, jak jest błąd walidacji to na 422 etc.

Tylko nie przesadz z tworzeniem tysiąca nowych typow wyjątkow bo to nie jest dobre. Lepiej bardziej ogolne niz milion konkretnych.
"Java's menagerie of exceptions is an anti-pattern"

Mappery są dość wygodne. Ale tez nie jestem jakims super fanem by wszystko w ten sposob rozwiazywac. Rzucanie wyjątku bo czegos nie ma w bazie danych nie wydaje mi sie byc sytuacją wyjątkową, zeby walic wyjątkami. W takim przypadku czemu nie Optional. A w przypadku listy czemu nie zwrocic po prostu pustej? itp. JVM/JIT itp. wcale nie lubia wyjatkow. http://normanmaurer.me/blog/2013/11/09/The-hidden-performance-costs-of-instantiating-Throwables/

Generalnie to lepiej probowac cos zwrocic niż sypać błędami.

albo podejsc do tematu nieco bardzoej funkcyjnie, uzyc Either, Try itp.

a Ty co myslisz Jarku @jarekr000000 ? ;)

Akurat Try, Either i Option(al) to się średnio z klasycznym podejściem springowym komponują. I niestety wynika to, z przyjętego przez springa modelu mapperów.

Jak to robimy w naszej jednej aplikacji. Kontroler przyjmuje request i jeżeli na tym etapie coś jest nie tak, to pozwalamy springowi zionąć wyjątkiem. Następnie dane z requestu zapakowane w DTO trafiają na warstwę komunikacyjną/dostępową. W tej warstwie następują przemapowania z DTO na obiekty domenowe i dalej lecimy do serwisów. Jeżeli jednak coś się w serwisach wysypie, to w tej warstwie mapujemy Try na odpowiedni wyjątek, który jest rzucany do kontrolera i niech się Spring dalej martwi.

Hej,
też mam pewną zagwozdkę związana z wyjątkami i informacjami w REST API.
Mianowicie mam REST API. Standardowo Controller,Service i DAO. Do tego utworzyłem pakiet exceptions do obsługi wyjątków i korzystam z @ControllerAdvice. Wszystko ładnie pięknie działa, kiedy chce pobrać dane z błędnym ID to zwraca status 404 z informacją. No i tu mam kilka pytań:

1. W której warstwie ten wyjątek powinien być wyrzucany( u mnie kontroler przyjmuje requesta i przekazuje do serwisu, ten pobiera z DAO i jeżeli jest null to zwraca wyjątek.)?
2. W której warstwie powinny być obsłużone wyjątki typowe dla DAO (np. brak połączenia ) ? Od razu w DAO czy puścić to wyżej do serwisu i tam to obsłużyć?
3. Powiedzmy, że moje API jest do sprzedaży biletów. No i jak zwrócić informację, że nie ma już biletów na sprzedaż.Też jako wyjątek z serwisu jak przy złym ID (tylko czy status jakiś tu powinien być wyrzucony?) czy jakoś inaczej?

@Janki:

1. Niech logika biznesowa zwraca do kontrolera Either<EnumBłedu,Wartość>, kontroler mapuje to sobię na odpowiednie ResponseEntity i nie trzeba wyjątków w ogóle. W najbardziej prostym przypadku (jak piszesz tylko wyszukanie czegoś w bazie) starczy Option/Optional. z mojego projektu:

@GetMapping("/league/{uuid}/results")
    public HttpEntity<LeagueResultsDTO> getResultsForLeague(@PathVariable UUID uuid) {
        Option<LeagueResultsDTO> leagueResultsDTOS = resultFacade.getResultsForLeague(uuid);
        return leagueResultsDTOS
                .map(dto -> new ResponseEntity<>(dto, HttpStatus.CREATED))
                .getOrElse(new ResponseEntity<>(HttpStatus.NOT_FOUND));
    }

1. Trochę zależy co chcesz zrobić. Jeśli jest to jakiś krytyczny błąd (brak bazy danych, brak neta) to lepiej czasem nawet złożyć całą aplikację. Rzucasz z miejsca gdzie coś się stało i tyle.
2. podobnie jak pkt 1

danek napisał(a):

@Janki:

1. Niech logika biznesowa zwraca do kontrolera Either<EnumBłedu,Wartość>, kontroler mapuje to sobię na odpowiednie ResponseEntity i nie trzeba wyjątków w ogóle. W najbardziej prostym przypadku (jak piszesz tylko wyszukanie czegoś w bazie) starczy Option/Optional. z mojego projektu:

Kopiuj

@GetMapping("/league/{uuid}/results")
    public HttpEntity<LeagueResultsDTO> getResultsForLeague(@PathVariable UUID uuid) {
        Option<LeagueResultsDTO> leagueResultsDTOS = resultFacade.getResultsForLeague(uuid);
        return leagueResultsDTOS
                .map(dto -> new ResponseEntity<>(dto, HttpStatus.CREATED))
                .getOrElse(new ResponseEntity<>(HttpStatus.NOT_FOUND));
    }

1. Trochę zależy co chcesz zrobić. Jeśli jest to jakiś krytyczny błąd (brak bazy danych, brak neta) to lepiej czasem nawet złożyć całą aplikację. Rzucasz z miejsca gdzie coś się stało i tyle.
2. podobnie jak pkt 1

hej @danek
dzięki trochę mi rozjaśniłeś, chodź nie chcę przerabiać już za bardzo tego co napisałem i chciałem zostać przy tym @ControllerAdvice.
Ciężko mi jakoś ogarnąć te wyjątki i jak nimi żonglować miedzy warstwami.
Jakby ktoś miał jakieś dobre przykłady lub znał artykuły to byłbym wdzięczny za link.

@Janki:

Ciężko mi jakoś ogarnąć te wyjątki i jak nimi żonglować miedzy warstwami.
Bo to takie krypto GOTO, też potem nie wiadomo co i jak sie dzieje ;)

:D ok ogarnę ile się da i zacznę raczkować, z czasem może rozjaśni się samo :)
dzięki @danek