ASP.NET MVC - obsługa wyjątków

Kiedy budujemy aplikację z ASP.NET MVC i robimy to za pomocą AJAX Musimy zachować szczególną ostrożność, patrząc na błędy, które nasz program może zwrócić.
Gdy żądanie się nie powiedzie, otrzymamy błąd serwera 500 co nie jest dobre dla użytkownika, a może otrzymujemy wiadomość ze śladem błędu od ASP.NET że jeśli nie przechwycimy go, zanim będzie można go zobaczyć na zewnątrz, a złośliwy użytkownik może uzyskać dane, aby z niego skorzystać i zaatakować naszą witrynę.
Aby uniknąć poważnych problemów, gdy nasza aplikacja zwróci błąd, musimy pracować nad obsługą ich jako wyjątków, aby zanim wystąpi błąd, nasza aplikacja mogła o tym wiedzieć i rzucić bardziej przyjazną dla użytkownika wiadomość, która nie zagraża naszemu bezpieczeństwu.
A wyjątek występuje, gdy część naszego kodu próbuje wykonać akcję i nie powiedzie się, próbując wysłać zapytanie o nieistniejące dane lub ponieważ nie weryfikujemy niektórych danych wejściowych użytkownika, jeśli używamy AJAX Możemy otrzymać błąd 500, ale jeśli tak się nie stanie, a do naszego kontrolera dotrą błędne dane, możemy uzyskać ślad błędu podobny do tego, który widzimy na poniższym obrazku:

ten ślady błędów Rzadko oferują one programistom przydatną ilość informacji, a jeśli nie wyczyścimy tego, co pokażemy, możemy zagrozić bezpieczeństwu witryny, filtrując dane konfiguracyjne z naszej aplikacji lub z naszego serwera.
Aby uniknąć wszystkich problemów, które mogą powstać w przypadku wystąpienia błędu w ASP.NET poradzimy sobie z takimi błędami jak wyjątki i w tym celu możemy przechwycić błąd i wysłać spersonalizowaną wiadomość lub po prostu wysłać odpowiedź, że strona, której szukasz, nie istnieje.
Czego użyćW tym celu możemy skorzystać z metody HttpResponseException który pozwala nam przekazać jako parametr a Kod HTTP jak strona 404 nie została znaleziona.
Na poniższym obrazku widzimy kod, który wykorzystuje wspomnianą metodę do obsługi wyjątku, zobaczmy:

POWIĘKSZAĆ

Tutaj to, co się dzieje jest dość proste, najpierw szukamy elementu po id, w przypadku, gdy zwraca pusty lub nieistniejący, dla naszego przykładu walidujemy go z null, ustawimy komunikat o błędzie metodą HttpResponseException ustawiamy kod not found i przygotowujemy niestandardową wiadomość, na koniec uruchamiamy tę wiadomość.
Dzięki temu unikamy wysyłania pustej lub pustej odpowiedzi na naszą aplikację co mogło w pewnym momencie spowodować jego awarię i niepoprawne wyświetlenie błędu, wysłaliśmy również bardziej przyjazną wiadomość do użytkownika, wyjaśniając, dlaczego jego zapytanie nie zwróciło wyników.
Uzyskując spersonalizowaną wiadomość, możemy również podać bardziej szczegółowe informacje, z których może skorzystać programista, łatwiej jest wiedzieć, że produkt nie istnieje, niż przeglądać 100-wierszowy ślad, aby dowiedzieć się tego samego.
Zakończyliśmy samouczek, dowiedziawszy się nieco więcej o ryzyku nieobsługiwania błędów, a także dowiedzieliśmy się, jak sobie z nimi radzić, traktując je jako wyjątki.