W swoich aplikacjach webowych na ogół staram się wykonywać obsługę błędów w następujący sposób: sytuacje, które mogę naprawić (np. wywołując kod w trochę inny sposób), opakowuję w try i w bloku catch staram się naprawić. Natomiast błędy, których nie jestem w stanie obsłużyć, zostawiam, a następnie dodaje globalną obsługę błędów w całej aplikacji. Same błędy są natomiast zapisywane przez bibliotekę Elmah.
Custom Errors
W przypadku aplikacji ASP.NET MVC (czy innych framework pochodnych ASP.NET) wykorzystuję mechanizm CustomErrors, który umożliwia wyświetlenie generycznego widoku z informacją o błędzie zamiast tak zwanego ekranu śmieci, który wyświetla informacje o błędzie. Widać to poniżej:
Custom Errors w ASP.NET MVC
Mając już ładny ekran z informacją o błędzie, potrzebuję jeszcze jakiegoś mechanizmu, który będzie mi te błędy zapisywał, a najlepiej jeszcze wysyłał na maila, abym mógł szybko zareagować na problem.
W ASP.NET MVC można zrobić to na wiele różnych sposobów. Możemy skorzystać z metody Application_Error z pliku Global.asax, możemy też skorzystać z filtru wyjątków. Niestety każde z tych rozwiązań wymaga napisania kodu, który na ogół jest taki sam w każdej tworzonej przeze mnie aplikacji. Dlaczego więc nie skorzystać z czegoś gotowego?
Elmah
Właśnie tytułowy ELMAH (https://elmah.github.io/) jest narzędziem, które bez pisania kodu umożliwia zrealizowanie logowania błędów oraz wysyłkę e-mail z informacją o błędzie.
Do aplikacji dodajemy bibliotekę z wykorzystaniem Nugeta. Już po tym nasza biblioteka działa poprawnie, czyli zbiera informację o błędach. Najlepiej to sprawdzić po wygenerowaniu jakiegoś błędu i przejściu pod adres [adres strony]/elmah.axd. Zobaczymy wtedy listę wszystkich zalogowanych błędów oraz możemy zobaczyć szczegóły poszczególnych wyjątków:
Elmah – zrzut ekranu błędu
Jak to widać na powyższych rysunkach, liczba informacji jest dość duża. Mamy treść wyjątku, stos wywołań i informacje o samym żądaniu do serwera (np. nazwa aktualnie zalogowanego użytkownika).
Niestety domyślna konfiguracja zapisuje błędy w pamięci procesu, przez co, jeśli nasza aplikacja się zrestartuje, informacje o wszystkich błędach stracimy. Dlatego warto nieco zmienić konfigurację biblioteki. Ja dodaję dwa wpisy:
| <errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data/elmah" /> | |
| <errorMail from="test@test.com" to="test@test.com" subject="Application Exception" async="false" smtpPort="25" smtpServer="***" userName="***" password="***" /> |
Pierwsza linia powoduje, że wszystkie błędy są zapisywane w plikach xml w katalogu ~/App_Data/elmah. Można również zapisać błędy w jakiejś bazie danych – wszystko zależy od potrzeb.
Druga linia powoduje wysłanie wiadomości e-mail z informacją o błędzie, dzięki czemu można szybko zareagować na występujący błąd.
Pracując z biblioteką ELMAH, warto pamiętać jeszcze o poprawnym zabezpieczeniu strony z błędami, ponieważ zawierają one szereg istotnych informacji o aplikacji i mogą pomóc ewentualnym atakującym naszą aplikację. Osobiście zabezpieczam ją na dwa sposoby. Po pierwsze odkomentowuję konfigurację autoryzacji w web.config, a po drugie zmieniam domyślny adres strony z błędami na coś w stylu [adres strony]/logs/elmah.axd.