Cześć, pytanie do zwolenników Vavra, Eithera i nie rzucania wyjątkami.
O ile błędy biznesowe wiadomo jak się obsługuje za pomocą powyższych tak mam pytanie jak mapujecie jakieś customowe techniczne wyjątki, które może rzucić Spring czy też JPA?
Jakieś uderzenia do zewnętrznych serwisów można opakować w Try.of(), a co z takimi, których nie ma jak ?
Bambo napisał(a):
Jakieś uderzenia do zewnętrznych serwisów można opakować w Try.of(), a co z takimi, których nie ma jak ?
Co to znaczy nie ma jak [opakować]? Na każdym fragmencie kody można zrobić Try.of()
Jeśli techniczny wyjątek to faktycznie wyjątek... to rzucam wyjątkiem i nie opakowuje.
Przykład - jak mam jakieś SQLException - to albo zrypałem zapytanie, albo coś jest nie tak z bazą danych
wtedy chcę jak najszybciej zakończyć aplikację (ew bieżącą funkcję) - nie ma co obsługiwać - tu trzeba uciekać i ograniczać szkody.
Wyjątki się do tego nadają dobrze.
Try.of to raczej łatka na coś co faktycznie wyjątkiem nie jest (kojarze, że ostatnio miałem coś takiego chyba przy obsłudze optimistic lock).
Albo mamy problem typu przekazywanie "wyjątku" między wątkami (chociaż na ogół i tak mamy ComplatableFuture i nie trzeba się w Try bawić).
Ok, ale jeśli chcemy ze względu security zabezpieczyć się na to, żeby odp ze springa nie powiedziała za dużo ? Chcemy zwrócić unknown error a nie casadra exception.
@jarekr000000
@ControllerAdvice
public class ErrorHandler {
private final static Logger LOG = LoggerFactory.getLogger(ErrorHandler.class);
@ExceptionHandler(SQLException.class)
public ResponseEntity<String> handleDbException(SQLException e) {
LOG.error("DB query failed.", e);
return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).build();
}
}
Możesz sobie tak przemapować cokolwiek na dowolną odpowiedź. Jak jesteś hardkorem to mozesz zwrócic 200 i stacktrace w jsonie #pdk
@Shalom: @Charles_Ray
Ok, to co jest powyżej z tym handlowaniem SQLException jest jasne, ale tutaj wiemy, że poleci SQLException i ok.
A co jeśli chcemy zabepieczyć się przed wyjątkami, których nie przewidujemy nawet? Nie podejrzewamy, że mogą wystąpić.
Oczywiście można sobie poczytać wszystkie dokumentacje, spisać listę wyjątków itd. a za pomocą ErrorHandlera jak powyżej jak to zrobić? Zapiąć się na Exception.class nie mogę xd.
Zapiąć się na Exception.class nie mogę xd
Bo? Nie bardzo rozumiem pytanie. Taka już dola z RuntimExceptions że sa niewidzialne i musiałbyś sprawdzić cały kod żeby wiedzieć kiedy i jakie mogą polecieć. Sam napisałes ze chcesz sie zabezpieczyć żeby nic nie leakować -> pokemon exception handling (gotta catch 'em all) i zwracasz na front tylko jakieś 500 i msg Wystąpił błąd, przepraszamy, nasi najlepsi ludzi już nad tym pracują i tyle ;]
Weź pod uwagę że to nie jest to samo co łapanie Exception gdzieś w kodzie. To jest handler który sie wykona na samym końcu, przed samą odpowiedzią i tutaj jak najbardziej powinieneś obsłużyć Exception.
Shalom napisał(a):
Możesz sobie tak przemapować cokolwiek na dowolną odpowiedź. Jak jesteś hardkorem to mozesz zwrócic 200 i stacktrace w jsonie #pdk
Całe życie z wariatami :D