Freigeben über

Verarbeiten von Ausnahmefehlern (VB)

  • Artikel

von Scott Mitchell

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Wenn ein Laufzeitfehler in einer Webanwendung in der Produktion auftritt, ist es wichtig, einen Entwickler zu benachrichtigen und den Fehler zu protokollieren, damit er zu einem späteren Zeitpunkt diagnostiziert werden kann. Dieses Lernprogramm bietet eine Übersicht darüber, wie ASP.NET Laufzeitfehler verarbeitet, und es wird eine Möglichkeit zum Ausführen von benutzerdefiniertem Code angezeigt, wenn eine unbehandelte Ausnahme bis zur ASP.NET Laufzeit bläht.

Einführung

Wenn eine unbehandelte Ausnahme in einer ASP.NET Anwendung auftritt, wird sie bis zur ASP.NET Laufzeit eingeblasen, wodurch das Error Ereignis ausgelöst wird und die entsprechende Fehlerseite angezeigt wird. Es gibt drei verschiedene Arten von Fehlerseiten: den Gelben Laufzeitfehlerbildschirm des Todes (YSOD); ausnahmedetails YSOD; und benutzerdefinierte Fehlerseiten. Im vorherigen Lernprogramm haben wir die Anwendung so konfiguriert, dass eine benutzerdefinierte Fehlerseite für Remotebenutzer und die Ausnahmedetails YSOD für Benutzer verwendet wird, die lokal besuchen.

Die Verwendung einer benutzerfreundlichen benutzerdefinierten Fehlerseite, die dem Erscheinungsbild der Website entspricht, wird dem standardmäßigen Laufzeitfehler YSOD bevorzugt, die Anzeige einer benutzerdefinierten Fehlerseite ist jedoch nur ein Teil einer umfassenden Fehlerbehandlungslösung. Wenn in einer Anwendung in der Produktion ein Fehler auftritt, ist es wichtig, dass die Entwickler über den Fehler benachrichtigt werden, damit sie die Ursache der Ausnahme lösen und beheben können. Darüber hinaus sollten die Fehlerdetails protokolliert werden, damit der Fehler zu einem späteren Zeitpunkt untersucht und diagnostiziert werden kann.

In diesem Lernprogramm wird gezeigt, wie Sie auf die Details einer unbehandelten Ausnahme zugreifen, damit sie protokolliert und ein Entwickler benachrichtigt werden kann. In den beiden Lernprogrammen, die auf dieses Beispiel folgen, werden Fehlerprotokollierungsbibliotheken untersucht, die Entwickler automatisch über Laufzeitfehler benachrichtigen und deren Details protokollieren.

Hinweis

Die in diesem Lernprogramm untersuchten Informationen sind am nützlichsten, wenn Sie unbehandelte Ausnahmen auf einzigartige oder angepasste Weise verarbeiten müssen. In Fällen, in denen Sie die Ausnahme nur protokollieren und einen Entwickler benachrichtigen müssen, ist die Verwendung einer Fehlerprotokollierungsbibliothek der Weg. Die nächsten beiden Lernprogramme bieten einen Überblick über zwei solche Bibliotheken.

Ausführen von Code beim Auslösen desErrorEreignisses

Ereignisse bieten ein Objekt einen Mechanismus zum Signalisieren, dass etwas Interessantes aufgetreten ist, und für ein anderes Objekt, um Code als Antwort auszuführen. Als ASP.NET Entwickler sind Sie daran gewöhnt, in Bezug auf Ereignisse zu denken. Wenn Sie Code ausführen möchten, wenn der Besucher auf eine bestimmte Schaltfläche klickt, erstellen Sie einen Ereignishandler für das Ereignis dieser Schaltfläche Click und fügen den Code dort ein. Da die ASP.NET Laufzeit das Error Ereignis auslöst, wenn eine unbehandelte Ausnahme auftritt, folgt es, dass der Code zum Protokollieren der Fehlerdetails in einen Ereignishandler wechselt. Aber wie erstellen Sie einen Ereignishandler für das Error Ereignis?

Das Error Ereignis ist eines der vielen Ereignisse in der HttpApplication Klasse , die während der Lebensdauer einer Anforderung in bestimmten Phasen der HTTP-Pipeline ausgelöst werden. Beispielsweise wird das Ereignis der HttpApplication Klasse BeginRequest zu Beginn jeder Anforderung ausgelöst. Das AuthenticateRequest Ereignis wird ausgelöst, wenn ein Sicherheitsmodul den Anforderer identifiziert hat. Diese HttpApplication Ereignisse geben dem Seitenentwickler eine Möglichkeit, benutzerdefinierte Logik an den verschiedenen Punkten der Lebensdauer einer Anforderung auszuführen.

Ereignishandler für die HttpApplication Ereignisse können in einer speziellen Datei mit dem Namen Global.asaxplatziert werden. Um diese Datei auf Ihrer Website zu erstellen, fügen Sie dem Stamm Ihrer Website ein neues Element mithilfe der Global Application Class-Vorlage mit dem Namen Global.asaxhinzu.

Screenshot des Hinzufügens eines neuen Elements zum Stamm ihrer Website mithilfe der Global Application Class-Vorlage mit dem Namen

Abbildung 1: Hinzufügen Global.asax zu Ihrer Webanwendung
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Der Inhalt und die Struktur der Global.asax von Visual Studio erstellten Datei unterscheiden sich geringfügig, je nachdem, ob Sie ein Webanwendungsprojekt (WEB Application Project, WAP) oder ein Websiteprojekt (Web Site Project, WSP) verwenden. Mit einem WAP wird die Global.asax Implementierung als zwei separate Dateien - Global.asax und Global.asax.vb. Die Global.asax Datei enthält nichts als eine @Application Direktive, die auf die .vb Datei verweist. Die interessanten Ereignishandler werden in der Global.asax.vb Datei definiert. Bei WSPs wird nur eine einzelne Datei erstellt, Global.asaxund die Ereignishandler werden in einem <script runat="server"> Block definiert.

Die Global.asax Datei, die in einer WAP von der Global Application Class-Vorlage von Visual Studio erstellt wurde, enthält Ereignishandler mit dem Namen Application_BeginRequest, Application_AuthenticateRequest, und Application_Error, die Ereignishandler für die HttpApplication Ereignisse BeginRequest, AuthenticateRequestbzw Error. . . Es gibt auch Ereignishandler namens Application_Start, , Session_Start, Application_Endund Session_End, die Ereignishandler sind, die beim Starten der Webanwendung ausgelöst werden, wenn eine neue Sitzung beginnt, wann die Anwendung endet, und wann eine Sitzung endet. Die Global.asax datei, die in einem WSP von Visual Studio erstellt wurde, enthält nur die Application_Error, Application_Start, Session_Start, , und Application_EndSession_End Ereignishandler.

Hinweis

Beim Bereitstellen der ASP.NET Anwendung müssen Sie die Global.asax Datei in die Produktionsumgebung kopieren. Die Global.asax.vb Datei, die im WAP erstellt wird, muss nicht in die Produktion kopiert werden, da dieser Code in die Assembly des Projekts kompiliert wird.

Die ereignishandler, die von der Global Application Class-Vorlage von Visual Studio erstellt wurden, sind nicht vollständig. Sie können einen Ereignishandler für jedes HttpApplication Ereignis hinzufügen, indem Sie den Ereignishandler Application_EventNamebenennen. Sie können beispielsweise der Global.asax Datei den folgenden Code hinzufügen, um einen Ereignishandler für das AuthorizeRequest Ereignis zu erstellen:

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

Ebenso können Sie alle Ereignishandler entfernen, die von der Global Application Class-Vorlage erstellt wurden, die nicht benötigt werden. Für dieses Lernprogramm benötigen wir nur einen Ereignishandler für das Error Ereignis. Sie können die anderen Ereignishandler aus der Global.asax Datei entfernen.

Hinweis

HTTP-Module bieten eine weitere Möglichkeit zum Definieren von Ereignishandlern für HttpApplication Ereignisse. HTTP-Module werden als Klassendatei erstellt, die direkt im Webanwendungsprojekt platziert oder in eine separate Klassenbibliothek getrennt werden kann. Da sie in eine Klassenbibliothek aufgeteilt werden können, bieten HTTP-Module ein flexibleres und wiederverwendbares Modell zum Erstellen von HttpApplication Ereignishandlern. Während die Global.asax Datei spezifisch für die Webanwendung ist, in der sie sich befindet, können HTTP-Module in Assemblys kompiliert werden, wodurch das Hinzufügen des HTTP-Moduls zu einer Website so einfach ist wie das Ablegen der Assembly im Bin Ordner und das Registrieren des Moduls in Web.config. Dieses Lernprogramm befasst sich nicht mit der Erstellung und Verwendung von HTTP-Modulen, aber die beiden in den folgenden beiden Lernprogrammen verwendeten Fehlerprotokollierungsbibliotheken werden als HTTP-Module implementiert. Weitere Hintergrundinformationen zu den Vorteilen von HTTP-Modulen finden Sie unter "Verwenden von HTTP-Modulen und Handlern zum Erstellen austauschbarer ASP.NET Komponenten".

Abrufen von Informationen über die unbehandelte Ausnahme

An diesem Punkt haben wir eine Global.asax-Datei mit einem Application_Error Ereignishandler. Wenn dieser Ereignishandler ausgeführt wird, müssen wir einen Entwickler über den Fehler benachrichtigen und seine Details protokollieren. Um diese Aufgaben auszuführen, müssen wir zuerst die Details der ausgelösten Ausnahme ermitteln. Verwenden Sie die Methode des ServerobjektsGetLastError, um Details der unbehandelten Ausnahme abzurufen, die dazu führte, dass das Error Ereignis ausgelöst wurde.

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

Die GetLastError Methode gibt ein Objekt vom Typ zurück Exception, bei dem es sich um den Basistyp für alle Ausnahmen im .NET Framework handelt. Im obigen Code umwandlung ich jedoch das Exception-Objekt, das von GetLastError einem HttpException Objekt zurückgegeben wird. Wenn das Error Ereignis ausgelöst wird, weil während der Verarbeitung einer ASP.NET Ressource eine Ausnahme ausgelöst wurde, wird die ausgelöste Ausnahme in eine HttpException. Verwenden Sie die Eigenschaft, um die tatsächliche Ausnahme abzurufen, die das Error-Ereignis InnerException ausgelöst hat. Wenn das Error Ereignis aufgrund einer HTTP-basierten Ausnahme ausgelöst wurde, z. B. eine Anforderung für eine nicht vorhandene Seite, wird ein HttpException Auslösen ausgelöst, hat jedoch keine innere Ausnahme.

Der folgende Code verwendet zum GetLastErrormessage Abrufen von Informationen über die Ausnahme, die das Error Ereignis ausgelöst hat, und speichert die HttpException in einer Variablen namens lastErrorWrapper. Anschließend wird der Typ, die Nachricht und die Stapelablaufverfolgung der ursprünglichen Ausnahme in drei Zeichenfolgenvariablen gespeichert, um festzustellen, ob es lastErrorWrapper sich um die tatsächliche Ausnahme handelt, die das Error Ereignis ausgelöst hat (bei HTTP-basierten Ausnahmen) oder wenn es sich lediglich um einen Wrapper für eine Ausnahme handelt, die beim Verarbeiten der Anforderung ausgelöst wurde.

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

An diesem Punkt verfügen Sie über alle Informationen, die Sie zum Schreiben von Code benötigen, der die Details der Ausnahme in einer Datenbanktabelle protokolliert. Sie können eine Datenbanktabelle mit Spalten für jede der interessanten Fehlerdetails erstellen – den Typ, die Nachricht, die Stapelablaufverfolgung usw. – zusammen mit anderen nützlichen Informationen, z. B. die URL der angeforderten Seite und den Namen des aktuell angemeldeten Benutzers. Application_Error Im Ereignishandler würden Sie dann eine Verbindung mit der Datenbank herstellen und einen Datensatz in die Tabelle einfügen. Ebenso könnten Sie Code hinzufügen, um einen Entwickler des Fehlers per E-Mail zu benachrichtigen.

Die in den nächsten beiden Lernprogrammen untersuchten Fehlerprotokollierungsbibliotheken bieten solche Funktionen sofort, daher ist es nicht erforderlich, diese Fehlerprotokollierung und Benachrichtigung selbst zu erstellen. Um jedoch zu veranschaulichen, dass das Error Ereignis ausgelöst wird und dass der Application_Error Ereignishandler verwendet werden kann, um Fehlerdetails zu protokollieren und einen Entwickler zu benachrichtigen, fügen wir Code hinzu, der einen Entwickler benachrichtigt, wenn ein Fehler auftritt.

Benachrichtigen eines Entwicklers, wenn eine unbehandelte Ausnahme auftritt

Wenn eine unbehandelte Ausnahme in der Produktionsumgebung auftritt, ist es wichtig, das Entwicklungsteam zu benachrichtigen, damit er den Fehler bewerten und bestimmen kann, welche Maßnahmen ergriffen werden müssen. Wenn beispielsweise beim Herstellen einer Verbindung mit der Datenbank ein Fehler auftritt, müssen Sie Ihre Verbindungszeichenfolge überprüfen und vielleicht ein Supportticket mit Ihrem Webhosting-Unternehmen öffnen. Wenn die Ausnahme aufgrund eines Programmierfehlers aufgetreten ist, müssen möglicherweise zusätzliche Code- oder Validierungslogik hinzugefügt werden, um solche Fehler in Zukunft zu verhindern.

Die .NET Framework-Klassen im System.Net.Mail Namespace erleichtern das Senden einer E-Mail. Die Klasse stellt eine E-Mail-Nachricht dar und verfügt über Eigenschaften wie To, From, , Subject, und BodyAttachments.MailMessage Das SmtpClass Objekt wird verwendet, um ein MailMessage Objekt mit einem angegebenen SMTP-Server zu senden. Die SMTP-Servereinstellungen können programmgesteuert oder deklarativ im Element in der <system.net> .Web.config file Weitere Informationen zum Senden von E-Mail-Nachrichten in einer ASP.NET Anwendung finden Sie in meinem Artikel, Senden von E-Mails von einer ASP.NET Webseitenwebsite und System.Net.Mail.

Hinweis

Das <system.net> Element enthält die SMTP-Servereinstellungen, die von der SmtpClient Klasse beim Senden einer E-Mail verwendet werden. Ihr Webhostingunternehmen verfügt wahrscheinlich über einen SMTP-Server, den Sie zum Senden von E-Mails von Ihrer Anwendung verwenden können. Weitere Informationen zu den SMTP-Servereinstellungen, die Sie in Ihrer Webanwendung verwenden sollten, finden Sie im Supportabschnitt Ihres Webhosts.

Fügen Sie dem Ereignishandler den Application_Error folgenden Code hinzu, um einem Entwickler eine E-Mail zu senden, wenn ein Fehler auftritt:

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

Während der obige Code ziemlich lang ist, erstellt der Großteil davon den HTML-Code, der in der E-Mail angezeigt wird, die an den Entwickler gesendet wird. Der Code verweist zunächst auf die HttpException von der GetLastError Methode (lastErrorWrapper) zurückgegebene. Die tatsächliche Ausnahme, die von der Anforderung ausgelöst wurde, wird über lastErrorWrapper.InnerException die Variable lastErrorabgerufen und zugewiesen. Die Typ-, Nachrichten- und Stapelüberwachungsinformationen werden aus lastError drei Zeichenfolgenvariablen abgerufen und gespeichert.

Als Nächstes wird ein benanntes MailMessage mm Objekt erstellt. Der E-Mail-Text ist HTML formatiert und zeigt die URL der angeforderten Seite, den Namen des aktuell angemeldeten Benutzers und Informationen zur Ausnahme an (Typ, Nachricht und Stapelüberwachung). Einer der coolen Dinge der HttpException Klasse besteht darin, dass Sie den HTML-Code generieren können, der zum Erstellen des "Exception Details Yellow Screen of Death" (YSOD) verwendet wird, indem Sie die GetHtmlErrorMessage-Methode aufrufen. Diese Methode wird hier verwendet, um das YSOD-Markup "Ausnahmedetails" abzurufen und der E-Mail als Anlage hinzuzufügen. Ein Wort mit Vorsicht: Wenn die Ausnahme, die das Error Ereignis ausgelöst hat, eine HTTP-basierte Ausnahme (z. B. eine Anforderung für eine nicht vorhandene Seite) war, gibt die GetHtmlErrorMessage Methode zurück null.

Der letzte Schritt besteht darin, das MailMessage. Dazu wird eine neue SmtpClient Methode erstellt und die Send Methode aufgerufen.

Hinweis

Bevor Sie diesen Code in Ihrer Webanwendung verwenden, sollten Sie die Werte in den und Konstanten in support@example.com die ToAddress E-Mail-Adresse FromAddress ändern, an die die E-Mail-Benachrichtigung gesendet werden soll und von der sie stammen soll. Außerdem müssen Sie die SMTP-Servereinstellungen im <system.net> Abschnitt in Web.config. Wenden Sie sich an Ihren Webhostanbieter, um die zu verwendenden SMTP-Servereinstellungen zu ermitteln.

Wenn dieser Code immer dann vorhanden ist, wenn ein Fehler auftritt, wird der Entwickler eine E-Mail-Nachricht gesendet, die den Fehler zusammenfasst und den YSOD enthält. Im vorherigen Lernprogramm haben wir einen Laufzeitfehler veranschaulicht, indem wir Genre.aspx besuchen und einen ungültigen ID Wert über die Abfragezeichenfolge übergeben, z Genre.aspx?ID=foo. B. . Das Aufrufen der Seite mit der Global.asax Datei erzeugt dieselbe Benutzererfahrung wie im vorherigen Lernprogramm – in der Entwicklungsumgebung sehen Sie weiterhin den Gelben Bildschirm "Ausnahmedetails" des Todes, während in der Produktionsumgebung die benutzerdefinierte Fehlerseite angezeigt wird. Zusätzlich zu diesem vorhandenen Verhalten wird der Entwickler eine E-Mail gesendet.

Abbildung 2 zeigt die beim Besuch Genre.aspx?ID=fooempfangene E-Mail. Der E-Mail-Text fasst die Ausnahmeinformationen zusammen, während die YSOD.htm Anlage den Inhalt anzeigt, der im Ausnahmedetails YSOD angezeigt wird (siehe Abbildung 3).

Screenshot der E-Mail, die mit ausnahmeinformationen empfangen wurde.

Abbildung 2: Der Entwickler wird immer dann eine E-Mail-Benachrichtigung gesendet, wenn es eine ausnahmefehler gibt.
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Screenshot der E-Mail-Benachrichtigung, die vom Entwickler empfangen wurde, wenn eine ausnahmefehlerige Ausnahme vorliegt.

Abbildung 3: Die E-Mail-Benachrichtigung enthält die Ausnahmedetails YSOD als Anlage
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Was ist mit der Verwendung der benutzerdefinierten Fehlerseite?

In diesem Lernprogramm wurde gezeigt, wie Global.asax Application_Error Der Ereignishandler zum Ausführen von Code verwendet wird, wenn eine unbehandelte Ausnahme auftritt. Insbesondere haben wir diesen Ereignishandler verwendet, um einen Entwickler über einen Fehler zu benachrichtigen; wir könnten sie erweitern, um auch die Fehlerdetails in einer Datenbank zu protokollieren. Das Vorhandensein des Application_Error Ereignishandlers wirkt sich nicht auf die Benutzeroberfläche des Endbenutzers aus. Sie sehen weiterhin die konfigurierte Fehlerseite, sei es die Fehlerdetails YSOD, die Laufzeitfehler-YSOD oder die benutzerdefinierte Fehlerseite.

Es ist natürlich, sich zu fragen, ob die Datei und Application_Error das Global.asax Ereignis bei Verwendung einer benutzerdefinierten Fehlerseite erforderlich sind. Wenn ein Fehler auftritt, wird dem Benutzer die benutzerdefinierte Fehlerseite angezeigt, weshalb der Code nicht eingefügt werden kann, um den Entwickler zu benachrichtigen und die Fehlerdetails in der CodeBehind-Klasse der benutzerdefinierten Fehlerseite zu protokollieren? Sie können der CodeBehind-Klasse der benutzerdefinierten Fehlerseite zwar codeBehind-Klasse hinzufügen, aber Sie haben keinen Zugriff auf die Details der Ausnahme, die das Error Ereignis ausgelöst hat, wenn sie die im vorherigen Lernprogramm beschriebene Technik verwenden. Das Aufrufen der GetLastError Methode von der benutzerdefinierten Fehlerseite gibt zurück Nothing.

Der Grund für dieses Verhalten ist, dass die benutzerdefinierte Fehlerseite über eine Umleitung erreicht wird. Wenn eine unbehandelte Ausnahme die ASP.NET Laufzeit erreicht, löst das ASP.NET-Modul sein Error Ereignis aus (das den Application_Error Ereignishandler ausführt), und leitet den Benutzer dann durch Ausgeben eines Response.Redirect(customErrorPageUrl)Fehlers auf die benutzerdefinierte Fehlerseite um. Die Response.Redirect Methode sendet eine Antwort auf den Client mit einem HTTP 302-Statuscode, in dem der Browser angewiesen wird, eine neue URL anzufordern, nämlich die benutzerdefinierte Fehlerseite. Der Browser fordert diese neue Seite dann automatisch an. Sie können feststellen, dass die benutzerdefinierte Fehlerseite separat von der Seite angefordert wurde, auf der der Fehler aufgetreten ist, da sich die Adressleiste des Browsers in die URL der benutzerdefinierten Fehlerseite ändert (siehe Abbildung 4).

Screenshot des Browsers, der an die Benutzerdefinierte Fehlerseite U R L umgeleitet wird, wenn ein Fehler auftritt.

Abbildung 4: Wenn ein Fehler auftritt, wird der Browser an die URL der benutzerdefinierten Fehlerseite umgeleitet.
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Der Nettoeffekt ist, dass die Anforderung, in der die unbehandelte Ausnahme aufgetreten ist, endet, wenn der Server mit der HTTP 302-Umleitung antwortet. Die nachfolgende Anforderung an die benutzerdefinierte Fehlerseite ist eine völlig neue Anforderung; An diesem Punkt hat das modul ASP.NET die Fehlerinformationen verworfen und hat darüber hinaus keine Möglichkeit, die unbehandelte Ausnahme in der vorherigen Anforderung der neuen Anforderung für die benutzerdefinierte Fehlerseite zuzuordnen. Aus diesem Grund GetLastError wird der Aufruf von der benutzerdefinierten Fehlerseite zurückgegeben null .

Es ist jedoch möglich, dass die benutzerdefinierte Fehlerseite während derselben Anforderung ausgeführt wird, die den Fehler verursacht hat. Die Server.Transfer(url) Methode überträgt die Ausführung an die angegebene URL und verarbeitet sie innerhalb derselben Anforderung. Sie könnten den Code im Application_Error Ereignishandler in die CodeBehind-Klasse der benutzerdefinierten Fehlerseite verschieben, indem Sie ihn Global.asax durch den folgenden Code ersetzen:

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

Wenn nun eine unbehandelte Ausnahme auftritt, überträgt der Application_Error Ereignishandler die Steuerung auf die entsprechende benutzerdefinierte Fehlerseite basierend auf dem HTTP-Statuscode. Da die Steuerung übertragen wurde, hat die benutzerdefinierte Fehlerseite Zugriff auf die unbehandelten Ausnahmeinformationen Server.GetLastError und kann einen Entwickler über den Fehler benachrichtigen und seine Details protokollieren. Der Server.Transfer Aufruf stoppt das ASP.NET Modul vom Umleiten des Benutzers zur benutzerdefinierten Fehlerseite. Stattdessen wird der Inhalt der benutzerdefinierten Fehlerseite als Antwort auf die Seite zurückgegeben, die den Fehler generiert hat.

Zusammenfassung

Wenn eine unbehandelte Ausnahme in einer ASP.NET Webanwendung auftritt, löst die ASP.NET Laufzeit das Error Ereignis aus und zeigt die konfigurierte Fehlerseite an. Wir können den Entwickler über den Fehler benachrichtigen, seine Details protokollieren oder auf andere Weise verarbeiten, indem wir einen Ereignishandler für das Error-Ereignis erstellen. Es gibt zwei Möglichkeiten zum Erstellen eines Ereignishandlers für HttpApplication Ereignisse wie : Errorin der Global.asax Datei oder aus einem HTTP-Modul. In diesem Lernprogramm wurde gezeigt, wie Sie einen Error Ereignishandler in der Global.asax Datei erstellen, der Entwickler über eine E-Mail-Nachricht benachrichtigt.

Das Erstellen eines Error Ereignishandlers ist nützlich, wenn Sie unbehandelte Ausnahmen auf eindeutige oder angepasste Weise verarbeiten müssen. Das Erstellen eines eigenen Error Ereignishandlers zum Protokollieren der Ausnahme oder zum Benachrichtigen eines Entwicklers ist jedoch nicht die effizienteste Verwendung Ihrer Zeit, da bereits freie und einfach zu verwendende Fehlerprotokollierungsbibliotheken vorhanden sind, die innerhalb weniger Minuten eingerichtet werden können. In den nächsten beiden Lernprogrammen werden zwei solche Bibliotheken untersucht.

Glückliche Programmierung!

Weitere nützliche Informationen

Weitere Informationen zu den in diesem Lernprogramm erläuterten Themen finden Sie in den folgenden Ressourcen:

ZurückWeiter