Wyświetlanie niestandardowej strony błędu (C#)
Autor : Scott Mitchell
Co widzi użytkownik w przypadku wystąpienia błędu w czasie wykonywania w aplikacji internetowej ASP.NET? Odpowiedź zależy od konfiguracji customErrors> witryny internetowej<. Domyślnie użytkownicy są wyświetlani niezręcznie żółty ekran z ogłoszeniem, że wystąpił błąd czasu wykonywania. W tym samouczku pokazano, jak dostosować te ustawienia, aby wyświetlić estetycznie przyjemną niestandardową stronę błędu zgodną z wyglądem i działaniem witryny.
Wprowadzenie
W idealnym świecie nie byłoby błędów czasu wykonywania. Programiści będą pisać kod z błędem nary i z niezawodną weryfikacją danych wejściowych użytkownika, a zasoby zewnętrzne, takie jak serwery baz danych i serwery poczty e-mail, nigdy nie przechodzą w tryb offline. Oczywiście błędy w rzeczywistości są nieuniknione. Klasy w .NET Framework sygnalizuje błąd, zgłaszając wyjątek. Na przykład wywołanie metody Open obiektu SqlConnection ustanawia połączenie z bazą danych określoną przez parametry połączenia. Jeśli jednak baza danych nie działa lub jeśli poświadczenia w parametrach połączenia są nieprawidłowe, metoda Open zgłasza błąd SqlException. Wyjątki mogą być obsługiwane przez użycie bloków try/catch/finally . Jeśli kod w try bloku zgłasza wyjątek, kontrolka zostanie przeniesiona do odpowiedniego bloku catch, w którym deweloper może podjąć próbę odzyskania po błędzie. Jeśli nie ma pasującego bloku catch lub jeśli kod, który rzucił wyjątek, nie znajduje się w bloku try, wyjątek przesłania stos wywołań w poszukiwaniu bloków try/catch/finally .
Jeśli wyjątek bąbelkuje aż do środowiska uruchomieniowego ASP.NET bez obsługi, HttpApplicationzostanie zgłoszone zdarzenie klasy Error i zostanie wyświetlona skonfigurowana strona błędu. Domyślnie ASP.NET wyświetla stronę błędu, która jest pieszczotliwie nazywana żółtym ekranem śmierci (YSOD). Istnieją dwie wersje modelu YSOD: jeden zawiera szczegóły wyjątku, ślad stosu i inne informacje przydatne dla deweloperów debugowania aplikacji (zobacz Rysunek 1); inne po prostu stwierdza, że wystąpił błąd czasu wykonywania (patrz Rysunek 2).
Szczegóły wyjątku YSOD są dość przydatne dla deweloperów debugowania aplikacji, ale wyświetlanie modelu YSOD dla użytkowników końcowych jest nieprofesjonalne i nieprofesjonalne. Zamiast tego użytkownicy końcowi powinni zostać przekierowani na stronę błędu, która utrzymuje wygląd i działanie witryny z bardziej przyjazną dla użytkownika prozy opisującą sytuację. Dobrą wiadomością jest to, że utworzenie takiej niestandardowej strony błędu jest dość proste. Ten samouczek rozpoczyna się od zapoznania się z platformą ASP. Różne strony błędów platformy NET. Następnie pokazano, jak skonfigurować aplikację internetową, aby pokazać użytkownikom niestandardową stronę błędu w obliczu błędu.
Badanie trzech typów stron błędów
Gdy wystąpi nieobsługiwany wyjątek w aplikacji ASP.NET jest wyświetlany jeden z trzech typów stron błędów:
- Strona błędu Szczegóły wyjątku — żółty ekran błędu śmierci,
- Strona błędu czasu wykonania — żółty ekran błędu śmierci lub
- Niestandardowa strona błędu
Deweloperzy strony błędów najbardziej znają szczegóły wyjątku YSOD. Domyślnie ta strona jest wyświetlana dla użytkowników odwiedzających lokalnie i w związku z tym jest stroną wyświetlaną, gdy wystąpi błąd podczas testowania witryny w środowisku programistycznym. Jak sama nazwa wskazuje, szczegóły wyjątku YSOD zawierają szczegółowe informacje o wyjątku — typ, komunikat i ślad stosu. Co więcej, jeśli wyjątek został zgłoszony przez kod w klasie za kod ASP.NET strony, a jeśli aplikacja jest skonfigurowana do debugowania, szczegóły wyjątku YSOD również pokaże ten wiersz kodu (oraz kilka wierszy kodu powyżej i poniżej).
Rysunek 1 przedstawia stronę Szczegóły wyjątku YSOD. Zanotuj adres URL w oknie adresu przeglądarki: http://localhost:62275/Genre.aspx?ID=foo. Pamiętaj, że strona Genre.aspx zawiera listę recenzji książek w określonym gatunku. Wymaga GenreId , aby wartość (a uniqueidentifier) była przekazywana przez ciąg zapytania, na przykład odpowiedni adres URL do wyświetlania recenzji fikcji to Genre.aspx?ID=7683ab5d-4589-4f03-a139-1c26044d0146. Jeśli wartość nieuniqueidentifier jest przekazywana przez ciąg zapytania (na przykład "foo"), zgłaszany jest wyjątek.
Uwaga
Aby odtworzyć ten błąd w demonstracyjnej aplikacji internetowej dostępnej do pobrania, możesz przejść Genre.aspx?ID=foo bezpośrednio lub kliknąć link "Generuj błąd czasu wykonania" w pliku Default.aspx.
Zwróć uwagę na informacje o wyjątku przedstawione na rysunku 1. Komunikat o wyjątku "Konwersja nie powiodła się podczas konwertowania z ciągu znaku na unikatowyidentifier" znajduje się w górnej części strony. Typ wyjątku, System.Data.SqlClient.SqlException, również jest wymieniony. Istnieje również ślad stosu.
Rysunek 1. Szczegóły wyjątku YSOD zawierają informacje o wyjątku
(Kliknij, aby wyświetlić obraz w pełnym rozmiarze)
Innym typem YSOD jest błąd czasu wykonania YSOD i jest wyświetlany na rysunku 2. Błąd czasu wykonania YSOD informuje odwiedzających o wystąpieniu błędu czasu wykonywania, ale nie zawiera żadnych informacji o zgłoszonym wyjątku. (Jednak udostępnia instrukcje dotyczące sposobu wyświetlania szczegółów błędu przez zmodyfikowanie Web.config pliku, co jest częścią tego, co sprawia, że taki YSOD wygląda nieprofesjonalnie).
Domyślnie błąd czasu wykonania YSOD jest wyświetlany użytkownikom odwiedzającym zdalnie (za pośrednictwem http://www.yoursite.com), zgodnie z adresem URL na pasku adresu przeglądarki na rysunku 2: http://httpruntime.web703.discountasp.net/Genre.aspx?ID=foo. Istnieją dwa różne ekrany YSOD, ponieważ deweloperzy są zainteresowani poznaniem szczegółów błędu, ale takie informacje nie powinny być wyświetlane w witrynie na żywo, ponieważ mogą ujawnić potencjalne luki w zabezpieczeniach lub inne poufne informacje dla każdego, kto odwiedza Witrynę.
Uwaga
Jeśli używasz DiscountASP.NET jako hosta internetowego, możesz zauważyć, że błąd czasu wykonania YSOD nie jest wyświetlany podczas odwiedzania witryny na żywo. Wynika to z tego, że DiscountASP.NET ma skonfigurowane serwery domyślnie wyświetlać szczegóły wyjątku YSOD. Dobrą wiadomością jest to, że można zastąpić to domyślne zachowanie, dodając sekcję <customErrors> do Web.config pliku. Sekcja "Konfigurowanie wyświetlanej strony błędu" szczegółowo analizuje sekcję <customErrors> .
Rysunek 2. Błąd czasu wykonania YSOD nie zawiera żadnych szczegółów błędu
(Kliknij, aby wyświetlić obraz w pełnym rozmiarze)
Trzeci typ strony błędu to niestandardowa strona błędu, która jest tworzoną stroną internetową. Zaletą niestandardowej strony błędu jest to, że masz pełną kontrolę nad informacjami wyświetlanymi użytkownikowi wraz z wyglądem i działaniem strony; niestandardowa strona błędu może używać tej samej strony wzorcowej i stylów co inne strony. Sekcja "Korzystanie z niestandardowej strony błędu" zawiera instrukcje tworzenia niestandardowej strony błędu i konfigurowania jej do wyświetlania w przypadku nieobsługiwanego wyjątku. Rysunek 3 zawiera szczyt tej niestandardowej strony błędów. Jak widać, wygląd i działanie strony błędu jest znacznie bardziej profesjonalne niż jeden z żółtych ekranów śmierci pokazanych na rysunkach 1 i 2.
Rysunek 3. Strona błędu niestandardowego oferuje bardziej dostosowany wygląd i działanie
(Kliknij, aby wyświetlić obraz w pełnym rozmiarze)
Poświęć chwilę na sprawdzenie paska adresu przeglądarki na rysunku 3. Zwróć uwagę, że na pasku Adres jest wyświetlany adres URL niestandardowej strony błędu (/ErrorPages/Oops.aspx). Na rysunkach 1 i 2 żółte ekrany śmierci są wyświetlane na tej samej stronie, z którą pochodzi błąd (Genre.aspx). Niestandardowa strona błędu jest przekazywana pod adres URL strony, na której wystąpił błąd za pośrednictwem parametru aspxerrorpath querystring.
Konfigurowanie wyświetlanej strony błędu
Która z trzech możliwych stron błędów jest wyświetlana na podstawie dwóch zmiennych:
- Informacje o konfiguracji w
<customErrors>sekcji i - Niezależnie od tego, czy użytkownik odwiedza witrynę lokalnie, czy zdalnie.
Sekcja<customErrors> w pliku Web.config ma dwa atrybuty wpływające na to, jaka strona błędu jest wyświetlana: defaultRedirect i mode. Atrybut defaultRedirect jest opcjonalny. Jeśli zostanie podany, określa adres URL niestandardowej strony błędu i wskazuje, że niestandardowa strona błędu powinna być wyświetlana zamiast błędu czasu wykonania YSOD. Atrybut mode jest wymagany i akceptuje jedną z trzech wartości: On, lub OffRemoteOnly. Te wartości mają następujące zachowanie:
On— wskazuje, że niestandardowa strona błędu lub błąd czasu wykonania YSOD jest pokazywana wszystkim odwiedzającym, niezależnie od tego, czy są lokalne, czy zdalne.Off- określa, że szczegóły wyjątku YSOD jest wyświetlany dla wszystkich odwiedzających, niezależnie od tego, czy są one lokalne, czy zdalne.RemoteOnly— wskazuje, że niestandardowa strona błędu lub błąd czasu wykonania YSOD jest pokazywany odwiedzającym zdalnym, podczas gdy szczegóły wyjątku YSOD są wyświetlane dla odwiedzających lokalnych.
Jeśli nie określisz inaczej, ASP.NET działa tak, jakby atrybut mode został ustawiony na RemoteOnly i nie określono defaultRedirect wartości. Innymi słowy, domyślne zachowanie polega na tym, że szczegóły wyjątku YSOD są wyświetlane dla odwiedzających lokalnych, podczas gdy błąd czasu wykonania YSOD jest wyświetlany osobom odwiedzającym zdalnym. To zachowanie domyślne można zastąpić, dodając sekcję <customErrors> do aplikacji internetowej Web.config file.
Używanie niestandardowej strony błędu
Każda aplikacja internetowa powinna mieć niestandardową stronę błędu. Zapewnia ona bardziej profesjonalną alternatywę dla błędu czasu wykonania YSOD, jest łatwa do utworzenia i skonfigurowanie aplikacji do korzystania z niestandardowej strony błędów zajmuje tylko kilka chwil. Pierwszym krokiem jest utworzenie niestandardowej strony błędu. Dodano nowy folder do aplikacji Recenzje książek o nazwie ErrorPages i dodano do niej nową stronę ASP.NET o nazwie Oops.aspx. Strona ma używać tej samej strony wzorcowej co pozostałe strony w witrynie, aby automatycznie dziedziczyła ten sam wygląd i działanie.
Rysunek 4. Tworzenie niestandardowej strony błędu
Następnie poświęć kilka minut na utworzenie zawartości strony błędu. Utworzono dość prostą niestandardową stronę błędu z komunikatem wskazującym, że wystąpił nieoczekiwany błąd i link z powrotem do strony głównej witryny.
Rysunek 5. Projektowanie niestandardowej strony błędu
(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)
Po zakończeniu strony błędu skonfiguruj aplikację internetową do używania niestandardowej strony błędu zamiast błędu czasu wykonania YSOD. Jest to realizowane przez określenie adresu URL strony błędu w <customErrors> atrybucie sekcji defaultRedirect . Dodaj następujący znacznik do pliku aplikacji Web.config :
<configuration>
...
<system.web>
<customErrors mode="RemoteOnly"
defaultRedirect="~/ErrorPages/Oops.aspx" />
...
</system.web>
</configuration>
Powyższy znacznik konfiguruje aplikację tak, aby wyświetlała szczegóły wyjątku YSOD użytkownikom odwiedzającym lokalnie, podczas gdy używasz niestandardowej strony błędu Oops.aspx dla tych użytkowników odwiedzających zdalnie. Aby zobaczyć tę akcję, wdróż witrynę internetową w środowisku produkcyjnym, a następnie odwiedź stronę Genre.aspx w witrynie na żywo z nieprawidłową wartością ciągu zapytania. Powinna zostać wyświetlona niestandardowa strona błędu (wróć do rysunku 3).
Aby sprawdzić, czy niestandardowa strona błędu jest wyświetlana tylko użytkownikom zdalnym, odwiedź Genre.aspx stronę z nieprawidłowym ciągiem zapytania ze środowiska deweloperskiego. Szczegóły wyjątku YSOD powinny być nadal widoczne (wróć do rysunku 1). Ustawienie RemoteOnly zapewnia, że użytkownicy odwiedzający witrynę w środowisku produkcyjnym zobaczą niestandardową stronę błędu, podczas gdy deweloperzy pracujący lokalnie nadal widzą szczegóły wyjątku.
Powiadamianie deweloperów i szczegóły błędu rejestrowania
Błędy występujące w środowisku projektowym były spowodowane przez dewelopera siedzącego na swoim komputerze. Jest wyświetlana informacja o wyjątku w elemecie Szczegóły wyjątku YSOD i wie, jakie kroki wykonywała podczas wystąpienia błędu. Jednak w przypadku wystąpienia błędu w środowisku produkcyjnym deweloper nie ma wiedzy, że wystąpił błąd, chyba że użytkownik końcowy odwiedzający witrynę zajmuje czas na zgłoszenie błędu. A nawet jeśli użytkownik wychodzi z drogi, aby powiadomić zespół deweloperów, że wystąpił błąd, bez znajomości typu wyjątku, komunikatu i śledzenia stosu może być trudno zdiagnozować przyczynę błędu, nie mówiąc już o jego naprawieniu.
Z tych powodów najważniejsze jest, aby każdy błąd w środowisku produkcyjnym był rejestrowany w niektórych magazynach trwałych (takich jak baza danych) i że deweloperzy są powiadamiani o tym błędzie. Niestandardowa strona błędu może wydawać się dobrym miejscem do wykonania tego rejestrowania i powiadomień. Niestety, niestandardowa strona błędu nie ma dostępu do szczegółów błędu i dlatego nie może być używana do rejestrowania tych informacji. Dobrą wiadomością jest to, że istnieje wiele sposobów przechwytywania szczegółów błędu i ich rejestrowania, a następne trzy samouczki bardziej szczegółowo zapoznają się z tym tematem.
Używanie różnych niestandardowych stron błędów dla różnych stanów błędów HTTP
Gdy wyjątek jest zgłaszany przez stronę ASP.NET i nie jest obsługiwany, wyjątek jest percolate do środowiska uruchomieniowego ASP.NET, który wyświetla skonfigurowaną stronę błędu. Jeśli żądanie wchodzi do aparatu ASP.NET, ale nie można go przetworzyć z jakiegoś powodu — być może żądany plik nie zostanie znaleziony lub uprawnienia do odczytu zostały wyłączone dla pliku — aparat ASP.NET zgłasza błąd HttpException. Ten wyjątek, taki jak wyjątki zgłaszane z ASP.NET stron, bąbelki do środowiska uruchomieniowego, powodując wyświetlenie odpowiedniej strony błędu.
Oznacza to, że w przypadku aplikacji internetowej w środowisku produkcyjnym, jeśli użytkownik żąda strony, która nie zostanie znaleziona, zostanie wyświetlona niestandardowa strona błędu. Rysunek 6 przedstawia taki przykład. Ponieważ żądanie dotyczy strony nieistniejącej (NoSuchPage.aspx), HttpException jest zgłaszana, a zostanie wyświetlona niestandardowa strona błędu (zanotuj odwołanie do NoSuchPage.aspx w parametrze aspxerrorpath querystring).
Rysunek 6. Środowisko uruchomieniowe ASP.NET wyświetla skonfigurowaną stronę błędu w odpowiedzi na nieprawidłowe żądanie (kliknij, aby wyświetlić obraz pełnowymiarowy)
Domyślnie wszystkie typy błędów powodują wyświetlenie tej samej niestandardowej strony błędu. Można jednak określić inną niestandardową stronę błędu dla określonego kodu stanu HTTP przy użyciu <error> elementów podrzędnych w <customErrors> sekcji. Aby na przykład wyświetlić inną stronę błędu w przypadku nie odnalezionego błędu strony, która ma kod stanu HTTP 404, zaktualizuj <customErrors> sekcję, aby uwzględnić następujące znaczniki:
<customErrors mode="RemoteOnly" defaultRedirect="~/ErrorPages/Oops.aspx">
<error statusCode="404" redirect="~/ErrorPages/404.aspx" />
</customErrors>
Dzięki tej zmianie zawsze, gdy użytkownik odwiedzający zdalnie żąda zasobu ASP.NET, który nie istnieje, zostanie przekierowany do niestandardowej 404.aspx strony błędu zamiast Oops.aspx. Jak pokazano na rysunku 7 , 404.aspx strona może zawierać bardziej szczegółowy komunikat niż ogólna niestandardowa strona błędu.
Uwaga
Zapoznaj się ze stronami błędów 404— jeszcze raz, aby uzyskać wskazówki dotyczące tworzenia skutecznych stron błędów 404.
Rysunek 7. Niestandardowa strona błędu 404 wyświetla bardziej docelowy komunikat niż Oops.aspx
(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)
Ponieważ wiadomo, że 404.aspx strona jest osiągana tylko wtedy, gdy użytkownik wysyła żądanie do strony, która nie została znaleziona, możesz ulepszyć tę niestandardową stronę błędu, aby uwzględnić funkcje ułatwiające użytkownikowi rozwiązanie tego konkretnego typu błędu. Na przykład można utworzyć tabelę bazy danych, która mapuje znane nieprawidłowe adresy URL na dobre adresy URL, a następnie na stronie błędu niestandardowego 404.aspx uruchomi zapytanie względem tej tabeli i sugeruje strony, z którymi użytkownik może próbować nawiązać połączenie.
Uwaga
Niestandardowa strona błędu jest wyświetlana tylko po wysłaniu żądania do zasobu obsługiwanego przez aparat ASP.NET. Jak omówiono w samouczku Podstawowe różnice między usługami IIS i serwerem ASP.NET Development Server , serwer internetowy może obsługiwać niektóre żądania. Domyślnie serwer internetowy usług IIS przetwarza żądania dotyczące zawartości statycznej, takiej jak obrazy i pliki HTML bez wywoływania aparatu ASP.NET. W związku z tym, jeśli użytkownik żąda nieistniejącego pliku obrazu, zostanie zwrócony domyślny komunikat o błędzie 404 usług IIS, a nie ASP. Skonfigurowana strona błędu platformy NET.
Podsumowanie
Gdy w aplikacji ASP.NET wystąpi nieobsługiwany wyjątek, użytkownik jest wyświetlany na jednej z trzech stron błędów: żółty ekran śmierci szczegóły wyjątku; Błąd czasu wykonania Żółty ekran śmierci; lub niestandardowa strona błędu. Która strona błędu jest wyświetlana, zależy od konfiguracji aplikacji <customErrors> i tego, czy użytkownik odwiedza lokalnie, czy zdalnie. Domyślnym zachowaniem jest wyświetlenie szczegółów wyjątku YSOD dla odwiedzających lokalnych i błędu czasu wykonania YSOD dla odwiedzających zdalnych.
Podczas gdy błąd czasu wykonywania YSOD ukrywa potencjalnie poufne informacje o błędzie od użytkownika odwiedzającego witrynę, przerywa wygląd i działanie witryny i sprawia, że aplikacja wygląda błędnie. Lepszym rozwiązaniem jest użycie niestandardowej strony błędu, która wiąże się z tworzeniem i projektowaniem niestandardowej strony błędu oraz określeniem jego adresu URL w <customErrors> atrybucie sekcji defaultRedirect . Można nawet mieć wiele niestandardowych stron błędów dla różnych stanów błędów HTTP.
Niestandardowa strona błędu to pierwszy krok w kompleksowej strategii obsługi błędów witryny internetowej w środowisku produkcyjnym. Alerty dewelopera błędu i rejestrowanie jego szczegółów są również ważnymi krokami. W następnych trzech samouczkach przedstawiono techniki powiadamiania o błędach i rejestrowania.
Szczęśliwe programowanie!
Dalsze informacje
Aby uzyskać więcej informacji na temat tematów omówionych w tym samouczku, zapoznaj się z następującymi zasobami: