Przetwarzanie nieobsługiwanych wyjątków (VB)

  • Artykuł

Autor : Scott Mitchell

Wyświetl lub pobierz przykładowy kod (jak pobrać)

W przypadku wystąpienia błędu w czasie wykonywania w aplikacji internetowej w środowisku produkcyjnym ważne jest powiadomienie dewelopera i zarejestrowanie błędu w celu zdiagnozowania go w późniejszym momencie. Ten samouczek zawiera omówienie sposobu, w jaki ASP.NET przetwarza błędy środowiska uruchomieniowego i analizuje jeden ze sposobów wykonywania kodu niestandardowego za każdym razem, gdy nieobsługiwane bąbelki wyjątku są uruchamiane do środowiska uruchomieniowego ASP.NET.

Wprowadzenie

Gdy w aplikacji ASP.NET wystąpi nieobsługiwany wyjątek, jest on bąbelkowy do środowiska uruchomieniowego ASP.NET, który zgłasza Error zdarzenie i wyświetla odpowiednią stronę błędu. Istnieją trzy różne typy stron błędów: żółty ekran śmierci (YSOD) błędu czasu wykonania; szczegóły wyjątku YSOD; i niestandardowe strony błędów. W poprzednim samouczku skonfigurowaliśmy aplikację tak, aby używała niestandardowej strony błędów dla użytkowników zdalnych i YSOD szczegółów wyjątku dla użytkowników odwiedzających się lokalnie.

Użycie przyjaznej dla człowieka niestandardowej strony błędu zgodnej z wyglądem i działaniem witryny jest preferowane do domyślnego błędu czasu wykonania YSOD, ale wyświetlanie niestandardowej strony błędów jest tylko jedną częścią kompleksowego rozwiązania do obsługi błędów. W przypadku wystąpienia błędu w aplikacji w środowisku produkcyjnym ważne jest, aby deweloperzy zostali powiadomieni o błędzie, aby mogli odkryć przyczynę wyjątku i rozwiązać go. Ponadto szczegóły błędu powinny być rejestrowane, aby można je było zbadać i zdiagnozować w późniejszym momencie.

W tym samouczku pokazano, jak uzyskać dostęp do szczegółów nieobsługiwanego wyjątku, aby można było je zarejestrować i powiadomić dewelopera. Dwa samouczki opisane w tym samouczku eksplorują biblioteki rejestrowania błędów, które po pewnym czasie konfiguracji będą automatycznie powiadamiać deweloperów o błędach środowiska uruchomieniowego i rejestrować ich szczegóły.

Uwaga

Informacje badane w tym samouczku są najbardziej przydatne, jeśli trzeba przetworzyć nieobsługiwane wyjątki w sposób unikatowy lub dostosowany. W przypadkach, gdy wystarczy zarejestrować wyjątek i powiadomić dewelopera, użycie biblioteki rejestrowania błędów jest sposobem na przejście. Dwa następne samouczki zawierają omówienie dwóch takich bibliotek.

Wykonywanie kodu po wystąpieniuErrorzdarzenia

Zdarzenia zapewniają obiekt mechanizm sygnalizujący, że wystąpiło coś interesującego, a dla innego obiektu do wykonania kodu w odpowiedzi. Jako deweloper ASP.NET jesteś przyzwyczajony do myślenia pod względem zdarzeń. Jeśli chcesz uruchomić kod, gdy gość kliknie określony przycisk, utworzysz procedurę obsługi zdarzeń dla zdarzenia tego przycisku Click i umieść tam kod. Biorąc pod uwagę, że środowisko uruchomieniowe ASP.NET zgłasza zdarzenieError za każdym razem, gdy wystąpi nieobsługiwany wyjątek, wynika z tego, że kod rejestrowania szczegółów błędu zostanie przekazany w procedurze obsługi zdarzeń. Ale jak utworzyć procedurę obsługi zdarzeń dla Error zdarzenia?

Zdarzenie Error jest jednym z wielu zdarzeń w HttpApplication klasie , które są wywoływane na niektórych etapach potoku HTTP w okresie istnienia żądania. Na przykład HttpApplication zdarzenie klasy BeginRequest jest zgłaszane na początku każdego żądania. ZdarzenieAuthenticateRequest jest zgłaszane, gdy moduł zabezpieczeń zidentyfikował obiekt żądającego. Te HttpApplication zdarzenia umożliwiają deweloperowi strony wykonywanie logiki niestandardowej w różnych punktach istnienia żądania.

Programy obsługi zdarzeń dla zdarzeń HttpApplication można umieścić w specjalnym pliku o nazwie Global.asax. Aby utworzyć ten plik w witrynie internetowej, dodaj nowy element do katalogu głównego witryny internetowej przy użyciu szablonu Global Application Class (Klasa aplikacji globalnej) o nazwie Global.asax.

Zrzut ekranu przedstawiający dodawanie nowego elementu do katalogu głównego witryny internetowej przy użyciu szablonu Global Application Class (Klasa aplikacji globalnej) o nazwie Global.asax w celu utworzenia tego pliku w witrynie internetowej.

Rysunek 1. Dodawanie Global.asax do aplikacji internetowej
(Kliknij, aby wyświetlić obraz w pełnym rozmiarze)

Zawartość i struktura pliku utworzonego Global.asax przez program Visual Studio różnią się nieznacznie w zależności od tego, czy używasz projektu aplikacji internetowej (WAP) czy projektu witryny sieci Web (WSP). W przypadku aplikacji WAP Global.asax element jest implementowany jako dwa oddzielne pliki — Global.asax i Global.asax.vb. Plik Global.asax zawiera tylko dyrektywę @Application , która odwołuje się do .vb pliku. W pliku są zdefiniowane Global.asax.vb programy obsługi zdarzeń. W przypadku dostawców WSP tworzony jest tylko jeden plik, Global.asaxa programy obsługi zdarzeń są definiowane w <script runat="server"> bloku.

Plik Global.asax utworzony w aplikacji WAP przez szablon globalnej klasy aplikacji programu Visual Studio zawiera programy obsługi zdarzeń o nazwach Application_BeginRequest, Application_AuthenticateRequesti Application_Error, które są procedurami obsługi zdarzeń odpowiednio dla HttpApplication zdarzeń BeginRequest, AuthenticateRequesti Error. Istnieją również programy obsługi zdarzeń o nazwach Application_Start, , Session_StartApplication_Endi Session_End, które są procedurami obsługi zdarzeń uruchamianymi po uruchomieniu aplikacji internetowej, po uruchomieniu nowej sesji, zakończeniu aplikacji i zakończeniu sesji. Plik Global.asax utworzony w programie WSP przez program Visual Studio zawiera tylko Application_Errorprogramy obsługi zdarzeń , Application_Start, Session_Start, Application_Endi Session_End .

Uwaga

Podczas wdrażania aplikacji ASP.NET należy skopiować Global.asax plik do środowiska produkcyjnego. Plik Global.asax.vb utworzony w aplikacji WAP nie musi być kopiowany do środowiska produkcyjnego, ponieważ ten kod jest kompilowany do zestawu projektu.

Programy obsługi zdarzeń utworzone przez szablon globalny klasy aplikacji programu Visual Studio nie są wyczerpujące. Program obsługi zdarzeń można dodać dla dowolnego HttpApplication zdarzenia, nazywając program obsługi Application_EventNamezdarzeń . Możesz na przykład dodać następujący kod do Global.asax pliku, aby utworzyć procedurę obsługi zdarzeń dla zdarzeniaAuthorizeRequest:

Sub Application_AuthorizeRequest(ByVal sender As Object, ByVal e As EventArgs)
    ' Event handler code
End Sub

Podobnie można usunąć wszystkie programy obsługi zdarzeń utworzone przez szablon Globalny klasa aplikacji, które nie są potrzebne. W tym samouczku potrzebujemy tylko programu obsługi zdarzeń dla Error zdarzenia. Możesz usunąć z pliku inne programy obsługi zdarzeń Global.asax .

Uwaga

Moduły HTTP oferują inny sposób definiowania procedur obsługi zdarzeń dla zdarzeń HttpApplication . Moduły HTTP są tworzone jako plik klasy, który można umieścić bezpośrednio w projekcie aplikacji internetowej lub rozdzielić na oddzielną bibliotekę klas. Ponieważ można je rozdzielić na bibliotekę klas, moduły HTTP oferują bardziej elastyczny i wielokrotnego użytku model do tworzenia HttpApplication procedur obsługi zdarzeń. Global.asax Podczas gdy plik jest specyficzny dla aplikacji internetowej, w której się znajduje, moduły HTTP można skompilować do zestawów, w tym momencie dodanie modułu HTTP do witryny internetowej jest tak proste, jak usunięcie zestawu w Bin folderze i zarejestrowanie modułu w Web.configprogramie . Ten samouczek nie obejmuje tworzenia i używania modułów HTTP, ale dwie biblioteki rejestrowania błędów używane w poniższych dwóch samouczkach są implementowane jako moduły HTTP. Aby uzyskać więcej informacji na temat zalet modułów HTTP, zobacz Using HTTP Modules and Handlers to Create Pluggable ASP.NET Components (Korzystanie z modułów HTTP i programów obsługi do tworzenia składników ASP.NET z możliwością podłączania).

Pobieranie informacji o nieobsługiwanym wyjątku

W tym momencie mamy plik Global.asax z procedurą Application_Error obsługi zdarzeń. Gdy ta procedura obsługi zdarzeń jest wykonywana, musimy powiadomić dewelopera o błędzie i zarejestrować jego szczegóły. Aby wykonać te zadania, najpierw musimy określić szczegóły zgłoszonego wyjątku. Użyj metody obiektu GetLastError Server, aby pobrać szczegóły nieobsługiwanego wyjątku, który spowodował Error wyzwolenie zdarzenia.

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
    ' Get the error details
    Dim lastErrorWrapper As HttpException = _
        CType(Server.GetLastError(), HttpException)
End Sub

Metoda GetLastError zwraca obiekt typu Exception, który jest typem podstawowym dla wszystkich wyjątków w .NET Framework. Jednak w powyższym kodzie rzutuję obiekt Exception zwrócony przez GetLastError element do HttpException obiektu . Error Jeśli zdarzenie jest wyzwalane, ponieważ podczas przetwarzania zasobu ASP.NET został zgłoszony wyjątek, wyjątek, który został zgłoszony, jest owinięty w obiekcie HttpException. Aby uzyskać rzeczywisty wyjątek, który wytrącił zdarzenie Error, użyj InnerException właściwości . Error Jeśli zdarzenie zostało zgłoszone z powodu wyjątku opartego na protokole HTTP, takiego jak żądanie dla nieistniejącej strony, HttpException zgłaszany jest wyjątek wewnętrzny, ale nie ma wyjątku wewnętrznego.

Poniższy kod używa elementu , GetLastErrormessage aby pobrać informacje o wyjątku, który wyzwolił Error zdarzenie, przechowując HttpException element w zmiennej o nazwie lastErrorWrapper. Następnie przechowuje typ, komunikat i ślad stosu wyjątku źródłowego w trzech zmiennych ciągu, sprawdzając, czy lastErrorWrapper jest to rzeczywisty wyjątek, który wyzwolił Error zdarzenie (w przypadku wyjątków opartych na protokole HTTP) lub jeśli jest to tylko otoka dla wyjątku, który został zgłoszony podczas przetwarzania żądania.

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
    ' Get the error details
    Dim lastErrorWrapper As HttpException = _
        CType(Server.GetLastError(), HttpException)

    Dim lastError As Exception = lastErrorWrapper
    If lastErrorWrapper.InnerException IsNot Nothing Then
        lastError = lastErrorWrapper.InnerException
    End If

    Dim lastErrorTypeName As String = lastError.GetType().ToString()
    Dim lastErrorMessage As String = lastError.Message
    Dim lastErrorStackTrace As String = lastError.StackTrace
End Sub

W tym momencie masz wszystkie informacje potrzebne do napisania kodu, który będzie rejestrować szczegóły wyjątku w tabeli bazy danych. Możesz utworzyć tabelę bazy danych z kolumnami dla każdego z interesujących cię szczegółów błędu — typu, komunikatu, śladu stosu itd. wraz z innymi przydatnymi informacjami, takimi jak adres URL żądanej strony i nazwa aktualnie zalogowanego użytkownika. W procedurze obsługi zdarzeń Application_Error połączysz się z bazą danych i wstawisz rekord do tabeli. Podobnie możesz dodać kod, aby powiadomić dewelopera o błędzie za pośrednictwem poczty e-mail.

Biblioteki rejestrowania błędów przeanalizowane w dwóch następnych samouczkach udostępniają takie funkcje gotowe do użycia, więc nie ma potrzeby samodzielnego kompilowania rejestrowania błędów i powiadamiania. Jednak aby zilustrować, że Error zdarzenie jest zgłaszane i że Application_Error program obsługi zdarzeń może służyć do rejestrowania szczegółów błędu i powiadamiania dewelopera, dodajmy kod, który powiadamia dewelopera o wystąpieniu błędu.

Powiadamianie dewelopera o wystąpieniu nieobsługiwanego wyjątku

Gdy w środowisku produkcyjnym wystąpi nieobsługiwany wyjątek, ważne jest, aby zaalarmować zespół deweloperów, aby mógł ocenić błąd i określić, jakie działania należy podjąć. Jeśli na przykład wystąpił błąd podczas nawiązywania połączenia z bazą danych, musisz dokładnie sprawdzić parametry połączenia i, być może, otworzyć bilet pomocy technicznej w firmie hostingu internetowego. Jeśli wyjątek wystąpił z powodu błędu programowania, może być konieczne dodanie dodatkowego kodu lub logiki walidacji, aby zapobiec takim błędom w przyszłości.

Klasy .NET Framework w System.Net.Mail przestrzeni nazw ułatwiają wysyłanie wiadomości e-mail. KlasaMailMessage reprezentuje wiadomość e-mail i ma właściwości, takie jak To, From, Subject, Bodyi Attachments. Obiekt SmtpClass jest używany do wysyłania MailMessage obiektu przy użyciu określonego serwera SMTP. Ustawienia serwera SMTP można określić programowo lub deklaratywnie w elemecie <system.net>Web.config filew obiekcie . Aby uzyskać więcej informacji na temat wysyłania wiadomości e-mail w aplikacji ASP.NET, zapoznaj się z artykułem Wysyłanie Email z witryny stron sieci Web ASP.NET i Często zadawane pytania dotyczące programu System.Net.Mail.

Uwaga

Element <system.net> zawiera ustawienia serwera SMTP używane przez klasę SmtpClient podczas wysyłania wiadomości e-mail. Twoja firma hostingowa internetowa prawdopodobnie ma serwer SMTP, którego można użyć do wysyłania wiadomości e-mail z aplikacji. Zapoznaj się z sekcją pomocy technicznej hosta internetowego, aby uzyskać informacje na temat ustawień serwera SMTP, których należy użyć w aplikacji internetowej.

Dodaj następujący kod do Application_Error programu obsługi zdarzeń, aby wysłać deweloperowi wiadomość e-mail w przypadku wystąpienia błędu:

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
    ' Get the error details
    Dim lastErrorWrapper As HttpException = _
        CType(Server.GetLastError(), HttpException)
    
    Dim lastError As Exception = lastErrorWrapper
    If lastErrorWrapper.InnerException IsNot Nothing Then
        lastError = lastErrorWrapper.InnerException
    End If

    Dim lastErrorTypeName As String = lastError.GetType().ToString()
    Dim lastErrorMessage As String = lastError.Message
    Dim lastErrorStackTrace As String = lastError.StackTrace

    Const ToAddress As String = "support@example.com"
    Const FromAddress As String = "support@example.com"
    Const Subject As String = "An Error Has Occurred!"

    ' Create the MailMessage object
    Dim mm As New MailMessage(FromAddress, ToAddress)
    mm.Subject = Subject
    mm.IsBodyHtml = True
    mm.Priority = MailPriority.High
  mm.Body = string.Format( _
"<html>" & vbCrLf & _
"  <body>" & vbCrLf & _
"  <h1>An Error Has Occurred!</h1>" & vbCrLf & _
"  <table cellpadding=""5"" cellspacing=""0"" border=""1"">" & vbCrLf & _
"  <tr>" & vbCrLf & _
"  <tdtext-align: right;font-weight: bold"">URL:</td>" & vbCrLf & _
"  <td>{0}</td>" & vbCrLf & _
"  </tr>" & vbCrLf & _
"  <tr>" & vbCrLf & _
"  <tdtext-align: right;font-weight: bold"">User:</td>" & vbCrLf & _
"  <td>{1}</td>" & vbCrLf & _
"  </tr>" & vbCrLf & _
"  <tr>" & vbCrLf & _
"  <tdtext-align: right;font-weight: bold"">Exception Type:</td>" & vbCrLf & _
"  <td>{2}</td>" & vbCrLf & _
"  </tr>" & vbCrLf & _
"  <tr>" & vbCrLf & _
"  <tdtext-align: right;font-weight: bold"">Message:</td>" & vbCrLf & _
"  <td>{3}</td>" & vbCrLf & _
"  </tr>" & vbCrLf & _
"  <tr>" & vbCrLf & _
"  <tdtext-align: right;font-weight: bold"">Stack Trace:</td>" & vbCrLf & _
"  <td>{4}</td>" & vbCrLf & _
"  </tr> " & vbCrLf & _
"  </table>" & vbCrLf & _
"  </body>" & vbCrLf & _
"</html>", _
  Request.RawUrl, _
  User.Identity.Name, _
  lastErrorTypeName, _
  lastErrorMessage, _
  lastErrorStackTrace.Replace(Environment.NewLine, "<br />"))

    'Attach the Yellow Screen of Death for this error
    Dim YSODmarkup As String = lastErrorWrapper.GetHtmlErrorMessage()
    If Not String.IsNullOrEmpty(YSODmarkup) Then
        Dim YSOD As Attachment = _
            Attachment.CreateAttachmentFromString(YSODmarkup, "YSOD.htm")
        mm.Attachments.Add(YSOD)
    End If

    ' Send the email
    Dim smtp As New SmtpClient()
    smtp.Send(mm)
End Sub

Chociaż powyższy kod jest dość długi, większość z niego tworzy kod HTML wyświetlany w wiadomości e-mail wysłanej do dewelopera. Kod rozpoczyna się od odwoływania HttpException się do zwracanego przez metodę GetLastError (lastErrorWrapper). Rzeczywisty wyjątek, który został zgłoszony przez żądanie, jest pobierany za pośrednictwem lastErrorWrapper.InnerException metody i jest przypisywany do zmiennej lastError. Informacje o typie, komunikacie i śledzeniu stosu są pobierane z lastError i przechowywane w trzech zmiennych ciągu.

Następnie zostanie MailMessage utworzony obiekt o nazwie mm . Treść wiadomości e-mail jest sformatowana w formacie HTML i wyświetla adres URL żądanej strony, nazwę aktualnie zalogowanego użytkownika oraz informacje o wyjątku (typ, wiadomość i ślad stosu). Jedną z ciekawych rzeczy dotyczących HttpException klasy jest to, że można wygenerować kod HTML używany do tworzenia żółtego ekranu śmierci szczegóły wyjątku (YSOD), wywołując metodę GetHtmlErrorMessage. Ta metoda jest używana w tym miejscu do pobierania znaczników YSOD szczegółów wyjątku i dodawania jej do wiadomości e-mail jako załącznika. Jedno słowo ostrożności: jeśli wyjątek, który wyzwolił Error zdarzenie, był wyjątkiem opartym na protokole HTTP (takim jak żądanie dla strony nieistniejącej), GetHtmlErrorMessage metoda zwróci nullwartość .

Ostatnim krokiem jest wysłanie polecenia MailMessage. W tym celu należy utworzyć nową SmtpClient metodę i wywołać jej Send metodę.

Uwaga

Przed użyciem tego kodu w aplikacji internetowej należy zmienić wartości w stałej ToAddress i FromAddress na support@example.com dowolny adres e-mail, do którego powinna zostać wysłana wiadomość e-mail z powiadomieniem o błędzie i z której pochodzi. Należy również określić ustawienia serwera SMTP w <system.net> sekcji w temacie Web.config. Skontaktuj się z dostawcą hosta sieci Web, aby określić ustawienia serwera SMTP do użycia.

Po utworzeniu tego kodu w dowolnym momencie zostanie wysłany komunikat e-mail z informacją o błędzie, który zawiera kod YSOD. W poprzednim samouczku pokazaliśmy błąd środowiska uruchomieniowego, odwiedzając Genre.aspx i przekazując nieprawidłową ID wartość za pośrednictwem ciągu zapytania, na przykład Genre.aspx?ID=foo. Odwiedzanie strony z Global.asax plikiem w miejscu powoduje utworzenie tego samego środowiska użytkownika co w poprzednim samouczku — w środowisku deweloperskim będziesz nadal widzieć żółty ekran śmierci szczegóły wyjątku, podczas gdy w środowisku produkcyjnym zostanie wyświetlona niestandardowa strona błędu. Oprócz tego istniejącego zachowania deweloper jest wysyłany pocztą e-mail.

Rysunek 2 przedstawia wiadomość e-mail odebraną podczas wizyty w programie Genre.aspx?ID=foo. Treść wiadomości e-mail zawiera podsumowanie informacji o wyjątku, podczas gdy YSOD.htm załącznik wyświetla zawartość wyświetlaną w module Szczegóły wyjątku YSOD (patrz Rysunek 3).

Zrzut ekranu przedstawiający wiadomość e-mail odebraną z informacjami o wyjątku.

Rysunek 2. Deweloper jest wysyłany Email powiadomienie za każdym razem, gdy wystąpi nieobsługiwany wyjątek
(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Zrzut ekranu przedstawiający powiadomienie e-mail odebrane przez dewelopera, gdy występuje nieobsługiwany wyjątek.

Rysunek 3. Powiadomienie Email zawiera szczegóły wyjątku YSOD jako załącznik
(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Co z używaniem niestandardowej strony błędu?

W tym samouczku pokazano, jak używać Global.asax programu obsługi zdarzeń i wykonywać kod po wystąpieniu Application_Error nieobsługiwanego wyjątku. W szczególności użyliśmy tej procedury obsługi zdarzeń, aby powiadomić dewelopera o błędzie; Możemy go rozszerzyć, aby również zarejestrować szczegóły błędu w bazie danych. Obecność programu obsługi zdarzeń Application_Error nie ma wpływu na środowisko użytkownika końcowego. Nadal widzą skonfigurowaną stronę błędu, czy to szczegóły błędu YSOD, błąd czasu wykonania YSOD lub niestandardową stronę błędu.

W przypadku korzystania z niestandardowej strony błędu naturalne jest zastanawianie się, czy Global.asax plik i Application_Error zdarzenie jest konieczne. Gdy wystąpi błąd, zostanie wyświetlona niestandardowa strona błędu, więc dlaczego nie możemy umieścić kodu, aby powiadomić dewelopera i zarejestrować szczegóły błędu w klasie kodowej niestandardowej strony błędu? Chociaż z pewnością możesz dodać kod do niestandardowej klasy kodu strony błędu, nie masz dostępu do szczegółów wyjątku, który wyzwolił Error zdarzenie podczas korzystania z techniki, którą omówiliśmy w poprzednim samouczku. GetLastError Wywołanie metody z niestandardowej strony błędu zwraca wartość Nothing.

Przyczyną tego zachowania jest to, że niestandardowa strona błędu jest osiągana za pośrednictwem przekierowania. Gdy nieobsługiwany wyjątek osiągnie środowisko uruchomieniowe ASP.NET aparat ASP.NET zgłasza zdarzenie Error (które wykonuje Application_Error program obsługi zdarzeń), a następnie przekierowuje użytkownika do niestandardowej strony błędu, wydając Response.Redirect(customErrorPageUrl)polecenie . Metoda Response.Redirect wysyła odpowiedź na klienta z kodem stanu HTTP 302, poinstruując przeglądarkę o zażądaniu nowego adresu URL, czyli niestandardowej strony błędu. Przeglądarka automatycznie żąda tej nowej strony. Możesz powiedzieć, że niestandardowa strona błędu została żądana oddzielnie od strony, na której pochodzi błąd, ponieważ pasek adresu przeglądarki zmienia się na niestandardowy adres URL strony błędu (zobacz Rysunek 4).

Zrzut ekranu przedstawiający przeglądarkę, która jest przekierowywana do niestandardowej strony błędu U R L po wystąpieniu błędu.

Rysunek 4. Gdy wystąpi błąd, przeglądarka zostanie przekierowana do niestandardowego adresu URL strony błędu
(Kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Efekt netto polega na tym, że żądanie, w którym wystąpił nieobsługiwany wyjątek, kończy się, gdy serwer odpowiada za pomocą przekierowania HTTP 302. Kolejne żądanie do niestandardowej strony błędu to zupełnie nowe żądanie; w tym momencie aparat ASP.NET odrzucił informacje o błędzie i, co więcej, nie ma możliwości skojarzenia nieobsługiwanego wyjątku w poprzednim żądaniu z nowym żądaniem dla niestandardowej strony błędu. GetLastError Dlatego zwraca wartość po null wywołaniu z niestandardowej strony błędu.

Istnieje jednak możliwość wykonania niestandardowej strony błędu podczas tego samego żądania, które spowodowało błąd. Metoda Server.Transfer(url) przenosi wykonanie do określonego adresu URL i przetwarza je w ramach tego samego żądania. Kod można przenieść w procedurze Application_Error obsługi zdarzeń do niestandardowej klasy kodowej strony błędu, zastępując go Global.asax następującym kodem:

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
    ' Get the error details
    Dim lastErrorWrapper As HttpException = _
        CType(Server.GetLastError(), HttpException)

    If lastErrorWrapper.GetHttpCode() = 404 Then
        Server.Transfer("~/ErrorPages/404.aspx")
    Else
        Server.Transfer("~/ErrorPages/Oops.aspx")
    End If
End Sub

Teraz, gdy wystąpi nieobsługiwany wyjątek Application_Error , program obsługi zdarzeń przenosi kontrolę do odpowiedniej niestandardowej strony błędu na podstawie kodu stanu HTTP. Ponieważ kontrolka została przeniesiona, niestandardowa strona błędu ma dostęp do informacji o nieobsługiwanym wyjątku za pośrednictwem Server.GetLastError programu i może powiadomić dewelopera o błędzie i zarejestrować jego szczegóły. Wywołanie Server.Transfer zatrzymuje aparat ASP.NET przekierowywanie użytkownika do niestandardowej strony błędu. Zamiast tego zawartość niestandardowej strony błędu jest zwracana jako odpowiedź na stronę, która wygenerowała błąd.

Podsumowanie

Gdy w aplikacji internetowej ASP.NET występuje nieobsługiwany wyjątek, środowisko uruchomieniowe ASP.NET zgłasza Error zdarzenie i wyświetla skonfigurowaną stronę błędu. Możemy powiadomić dewelopera o błędzie, zarejestrować jego szczegóły lub przetworzyć je w inny sposób, tworząc procedurę obsługi zdarzeń dla zdarzenia Błąd. Istnieją dwa sposoby tworzenia procedury obsługi zdarzeń dla HttpApplication zdarzeń, takich jak Error: w pliku lub z modułu Global.asax HTTP. W tym samouczku pokazano, jak utworzyć Error program obsługi zdarzeń w Global.asax pliku, który powiadamia deweloperów o błędzie za pomocą wiadomości e-mail.

Error Tworzenie procedury obsługi zdarzeń jest przydatne, jeśli musisz przetworzyć nieobsługiwane wyjątki w sposób unikatowy lub dostosowany. Jednak tworzenie własnej Error procedury obsługi zdarzeń w celu rejestrowania wyjątku lub powiadamianie dewelopera nie jest najbardziej wydajnym użyciem czasu, ponieważ istnieje już bezpłatna i łatwa w użyciu bibliotek rejestrowania błędów, które mogą być skonfigurowane w ciągu kilku minut. Dwa następne samouczki badają dwie takie biblioteki.

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:

WsteczDalej