Błędy w aplikacjach internetowych (desktopowych również) były, są i będą tak długo jak człowiek będzie uczestniczył w procesie ich tworzenia, a jak na razie nie zanosi się aby komputery same pisały oprogramowanie. Dlatego też należy zadbać o odpowiednią ich obsługę.
Błędy można podzielić na dwie grupy: błędy czasu kompilacji i błędy czasu wykonania. Te pierwsze zazwyczaj wynikają z błędów w składni skryptów i zwykle objawiają się przy próbie kompilacji (np. ASP.NET) lub wywołania strony (np. PHP) w oknie przeglądarki – zamiast oczekiwanej treści pojawi się tam komunikat o błędzie. Z tego tez powodu ich odnalezienie jest proste.
Drugą kategorią błędów są błędy czasu wykonania. Od tych pierwszych różnią się tym że objawiają się dopiero w działającym systemie. Część z nich jest wykrywana szybko, gdyż ich skutki pojawiają się podczas wykonywania typowych operacji w tworzonym serwisie WWW. Niestety wiele z nich objawia się dopiero w pewnych określonych warunkach, przez co mogą zupełnie przejść niezauważone. Te błędy jednak dalej istnieją i mogą objawić się w najmniej oczekiwanym momencie. Pół biedy jeżeli jedynym efektem błędu będzie np. „rozjechanie się” strony internetowej – znacznie gorzej będzie jeżeli błąd spowoduje niemożność złożenia zamówienia, utratę danych lub pozwoli włamać się do serwisu WWW.
Błędy czasu wykonania można z grubsza podzielić na trzy kategorie:
- błędy oczekiwane;
- błędy nieoczekiwane obsłużone;
- błędy nieoczekiwane nieobsłużone.
Błędy oczekiwane są to błędy których wystąpienie jest oczywiste i oczekiwane. Przykładem może być np. funkcja odczytująca kolejne wiersze z pliku. Jeżeli funkcja zwróci błąd będzie to oznaczać że dane w pliku się skończyły.
Druga kategoria to błędy nieoczekiwane obsłużone. Są to te błędy które zwykle nie występują (np. wykonanie zapytania na bazie danych zazwyczaj się udaje), ale w pewnych sytuacjach mogą się one pojawić (np. administrator postanowił zrestartować serwer baz danych). Skrypt jest jednak na to przygotowany i odpowiednio to obsłuży, np. wyświetli stosowny komunikat błędu.
Ostatnią kategorią są błędy nieoczekiwane nieobsłużone. Są to wszystkie te błędy na które nie jesteśmy przygotowani, a ich pojawienie się często sygnalizuje strona z napisem „Wystąpił nieoczekiwany błąd. Proszę skontaktować się z administratorem systemu”, lub strona zawierająca sam komunikat błędu.
Warto także pamiętać o tym że internauci są zwykle bardzo leniwi i jednocześnie niecierpliwi – jeżeli strona nie działa, to zazwyczaj nie będą się trudzić się odszukaniem formularza kontaktowego czy adresu email właściciela strony aby wysłać zgłoszenie o błędzie. Zamiast tego po prostu zamkną stronę i poszukają sobie innej, ew. ponarzekają sobie na forach dyskusyjnych i w komentarzach do artykułów na innych stronach. Świeży jeszcze przykład: prowadzę stronę o jednym z reality show. Przez miesiąc na ten stronie pojawiały się wpisy że są problemy z wypełnianiem formularza zgłoszeniowego do kolejnej edycji programu. Było to akurat w okresie świąt Bożego Narodzenia i Nowego Roku, więc ludzie siedzieli po domach i mieli dużo wolnego czasu, ale pomimo tego nikt najwyraźniej nie zgłosił tych problemów wysyłając maila pod odpowiedni adres, ew. były to maile typu „Pomocy, nie działa” (krótko mówiąc trzeba mieć jasnowidza na etacie ;)). Gdy w końcu sam postanowiłem coś z tym zrobić i wysłałem maila, problemy zostały rozwiązane w ciągu jednego dnia.
Ponieważ zatem na odwiedzających stronę nie ma co liczyć jako na osoby zgłaszające błędy, należy samemu o to zadbać. Dotyczy to zarówno błędów nieoczekiwanych nieobsłużonych, jak i tych obsłużonych. Z praktyki wiem że bardzo dobrze sprawdza się zainstalowanie funkcji która pozbiera wszystkie interesujące dane (gdzie i jaki błąd wystąpił, wartości zmiennych GET, POST, Cookies, zmienne środowiskowe, zmienne globalne i wszystko inne co może być przydatne) i np. wysłał je mailem do odpowiedniej osoby. Dzięki tym danym zreprodukowanie błędu jest zazwyczaj bardzo proste, a to jest pierwszy krok na drodze do ustalenia gdzie jest błąd i jego wyeliminowania.
W przypadku błędów nieoczekiwanych obsłużonych trzeba odnaleźć miejsca gdzie jest kod obsługi błędów, i dodać tam wywołanie funkcji tworzącej raport o błędzie. Jest to robota raczej łatwa, co najwyżej jedynie może być czasochłonna.
Możliwość przechwytywania błędów nieoczekiwanych nieobsłużonych zależy od konkretnego języka. Na szczęście zazwyczaj tak jest – w przypadku PHP dostępne są funkcje set_error_handler() i set_exception_handler() (ta druga tylko w PHP5) pozwalające na zainstalowanie własnej funkcji obsługi błędów. W przypadku ASP można w opcjach konfiguracji serwera IIS ustawić plik ASP do którego ma być przekazane sterowanie po wystąpieniu błędu. W pliku tym jest dostęp do wszystkich interesujących danych, a informacje o ostatnim błędzie można pobrać za pomocą funkcji Server.GetLastError(). ASP.NET z kolei posiada zdarzenie Event w klasie System.Web.HttpApplication, które zostanie wywołane po wystąpieniu takiego błędu.
Mam nadzieję że dzięki temu artykułowi uda Ci się zaimplementować na swojej stronie WWW system automatycznego raportowania o wystąpieniu błędu, i po jakimś czasie błędy przestaną Ci się śnić po nocach. Dzięki temu będziesz też mógł/mogła odpowiedzieć dzwoniącemu czy mailującemu klientowi „wiem o tym błędzie i właśnie go poprawiam, za godzinę powinno już być OK” zamiast „zaraz to sprawdzę i zobaczę ile mi zajmie poprawienie tego”.
Komentarze