[Khaine]

#programowanie #webdev #csharp

Czy w Web API powinno się w ogóle catchować wyjątki w kontrolerach? Zrobiłem sobie już zapięcie pod globalny catcher, który wyświetla jakiś bardziej przyjazny napis + Exception.Message żeby była dla użytkownika albo raczej przede wszystkim przy tworzeniu frontu jakaś poszlaka co się wysrało, żeby łatwiej można było potem przetrzepać logi - to powinno załatwić obsługę wszystkiego co wysra się niespodziewanie.

No i jeszcze można catchować wyjątki "obsłużone" gdy wiemy co się wysrało - przykładowo ktoś spróbował zrobić inserta użytkownika, który już istnieje, czego można się spodziewać i nie trzeba rzygać jakimś syfem z bazy danych, tylko odesłać odpowiedni message (no bo to nie będzie 500 "yy coś w------o", tylko raczej 400 bad request "zmień nazwę typie").

Coś jeszcze się robi czy to tyle na temat wyjątków? W desktopach trzeba było bardziej uważać, bo bardzo prosto o utratę stabilności aplikacji gdy coś się zesra praktycznie gdziekolwiek, tutaj wydaje mi się że te globalne catchery i ogólna natura tego jak działa takie API nie stwarzają potrzebny zbytniego niańczenia.

[Szab]

Coś jeszcze się robi czy to tyle na temat wyjątków?

@Khaine: Można jeszcze je gdzieś zalogować, ale poza tym to raczej tyle.

[Khaine]

@Szab: Logowanie jest automatyczne. Nawet nie muszę robić Ilogger.LogError, bo to od razu leci z tego co widzę do konsoli w pełnej postaci - a co leci do konsoli siedzi w rurce logów, więc można sobie to zrzucić jakimś listenerem gdziekolwiek, do pliku czy bazy. Ale to już kwestia podpięcia się pod logi aniżeli samej obsługi wyjątków.

[C.....y]

@Khaine na to co wymieniasz w 2 akapicie służy walidacja a nie try/catch, polecam choćby FluentValidation

Odnośnie samego catch to zwróci się po prostu 500 albo 404 i tyle, nic się tam na produkcji nie wywali, ja w ogóle nie stosuję tam catchy chyba że podczas debugowania bo częściej przeszkadzają niż pomagają. W desktopach/serwisach dla stabilności aplikacji obowiązkowo, ale lubię czasem trafić na legacy code z pustym catchem i szukać go

[Khaine]

W desktopach/serwisach dla stabilności aplikacji obowiązkowo, ale lubię czasem trafić na legacy code z pustym catchem i szukać go po kodzie xD

@Czarzy: Ja to czasem lubię jak w-----e, bo chociaż wiadomo gdzie xD A jak ktoś zrobi catch(Exception e) { } to powodzenia xD W web api globalny catcher to złapie i wrzuci do loga jako fail, to się znajdzie.

[object]

@Khaine: może lepiej po prostu obsłużyć ten wyjątek i zwrócić odpowiedni response do klienta? Skoro wiesz, że może się pojawić to czemu nie.

[Khaine]

@object: No tak jak mówiłem, wyjątki których się spodziewam obsługuję inaczej. Jeśli wiem jaki kod SQL może wystąpić podczas jakiegoś przewidywalnego scenariusza, to nie ma powodu aby rzygać jakimiś błędami w response, skoro taka sytuacja to normalny scenariusz użycia - błędnego tak dokładniej.