Obsługa błędów w aplikacjach internetowych - część 2

W pierwszej części tego artykułu dokonałem wprowadzenia do zagadnienia obsługi błędów w aplikacjach internetowych i przedstawiłem zarysy mechanizmu automatycznego ich raportowania. W tej części będę kontynuował ten temat.

Przedstawiony wcześniej mechanizm automatycznego raportowania błędów zazwyczaj sprawdza się dobrze. Piszę "zazwyczaj" ponieważ miałem jedną sytuację gdy pomimo posiadania raportu o błędzie nie byłem w stanie go zreprodukować - moja aplikacja internetowa w pewnym momencie zaczynała wykonywać pewien fragment kodu co skutkowało błędem. Teoretycznie jednak nie powinna była go w ogóle uruchomić, i nie miałem pomysłu dlaczego tak się dzieje.

Przeszkodą okazał się tutaj fakt że raporty o błędach były "statyczne" - zawierały one dokładną informację o stanie aplikacji w momencie wystąpienia błędu, ale nie było tam informacji o tym co się działo wcześniej. Postanowiłem zatem dodać mechanizm który by logował także takie informacje.

Rozwiązanie które zastosowałem polegało na dodaniu do obiektu sesji dodatkowego obiektu który przechowywałby informacje o ostatnich zdarzeniach (ja zdecydowałem się na pamiętanie 40 ostatnich zdarzeń, po przekroczeniu tej liczby najstarsze wpisy były sukcesywnie usuwane). Ponieważ wszystkie dane sesji były dołączane do raportu o błędzie, więc lista ostatnich zdarzeń też tam się pojawiała.

Zdarzenia które logowałem to były przede wszystkim informacje o wywołaniach stron. Jeżeli strona prezentowała różne dane, dodawałem także identyfikator który jednoznacznie te dane identyfikował. W przypadku stron które mogły prezentować dane na kilka sposobów (np. lista produktów i informacje szczegółowe o wybranym produkcie), dodawałem także informacje jak dane są wyświetlane. Dodatkowo kod odpowiedzialny za przełączanie widoku lista/szczegóły logował też fakt że użytkownik zażyczył sobie zmiany widoku.

Dzięki zastosowaniu tego rozwiązania błąd odnalazłem już stosunkowo szybko - użytkownik po wypełnieniu mojego formularza korzystał z przycisku "Wstecz" w przeglądarce i wracał do jednej z pierwszych stron. Ponieważ jednak aplikacja nie przewidywała takiej sytuacji, skutkowało to błędem i mailem z raportem o nim. Poprawienie jego już było proste.

Jak być może zwróciłeś(aś) uwagę, ograniczyłem liczbę logowanych zdarzeń do 40. Zrobiłem tak aby nadmiernie nie zwiększać zużycia pamięci, a jednocześnie aby mieć wystarczająco dużo informacji do analizy. W przypadku mojego błędu wystarczyło mi kilkanaście wpisów z logu, aby odkryć jego przyczynę, więc w praktyce limit 20 wpisów byłby dla mnie wystarczający.

Jak zatem widać, nie zawsze statyczny zrzut stanu aplikacji wystarcza do znalezienia odpowiedzi na pytanie dlaczego błąd wystąpił. Czasami potrzeba też przeanalizować kilka lub kilkanaście ostatnich wykonanych przez użytkownika kroków, aby móc odkryć przyczynę błędu. Dzięki rozwiązaniu które tutaj opisałem jest to możliwe.

Wykop tą stronę! >>>