Freigeben über

Anzeigen einer benutzerdefinierten Fehlerseite (VB)

  • Artikel

von Scott Mitchell

Was wird dem Benutzer angezeigt, wenn in einer ASP.NET Webanwendung ein Laufzeitfehler auftritt? Die Antwort hängt davon ab, wie die customErrors-Konfiguration> der <Website ist. Standardmäßig wird Benutzern ein unschöner gelber Bildschirm angezeigt, der angibt, dass ein Laufzeitfehler aufgetreten ist. In diesem Tutorial erfahren Sie, wie Sie diese Einstellungen anpassen, um eine ästhetisch ansprechende benutzerdefinierte Fehlerseite anzuzeigen, die dem Aussehen und Verhalten Ihrer Website entspricht.

Einführung

In einer perfekten Welt würde es keine Laufzeitfehler geben. Programmierer schreiben Code mit einem Fehler und einer robusten Überprüfung der Benutzereingabe, und externe Ressourcen wie Datenbankserver und E-Mail-Server würden nie offline gehen. Natürlich sind Fehler in Wirklichkeit unvermeidlich. Die Klassen in der .NET Framework einen Fehler signalisieren, indem sie eine Ausnahme auslösen. Wenn Sie beispielsweise die Open-Methode eines SqlConnection-Objekts aufrufen, wird eine Verbindung mit der durch eine Verbindungszeichenfolge angegebenen Datenbank hergestellt. Wenn die Datenbank jedoch ausgefallen ist oder die Anmeldeinformationen in der Verbindungszeichenfolge ungültig sind, löst die Open-Methode einen aus SqlException. Ausnahmen können mithilfe von Blöcken Try/Catch/Finally behandelt werden. Wenn code in einem Try Block eine Ausnahme auslöst, wird die Steuerung an den entsprechenden Catch-Block übertragen, in dem der Entwickler versuchen kann, den Fehler wiederherzustellen. Wenn kein übereinstimmender Catch-Block vorhanden ist oder sich der Code, der die Ausnahme ausgelöst hat, nicht in einem Try-Block befindet, wird die Aufrufliste bei der Try/Catch/Finally Suche nach Blöcken durch die Ausnahme nach oben gestapelt.

Wenn die Ausnahme bis zur ASP.NET Runtime in eine Blase eingeblendet wird, ohne behandelt zu werden, wird das -Ereignis derErrorHttpApplication -Klasse ausgelöst, und die konfigurierte Fehlerseite wird angezeigt. Standardmäßig zeigt ASP.NET eine Fehlerseite an, die liebevoll als Gelber Bildschirm des Todes (YSOD) bezeichnet wird. Es gibt zwei Versionen des YSOD: eine zeigt die Ausnahmedetails, eine Stapelüberwachung und andere Informationen, die für Entwickler beim Debuggen der Anwendung hilfreich sind (siehe Abbildung 1); Der andere gibt einfach an, dass ein Laufzeitfehler aufgetreten ist (siehe Abbildung 2).

Die Ausnahmedetails YSOD ist für Entwickler, die die Anwendung debuggen, sehr hilfreich, aber das Anzeigen eines YSOD für Endbenutzer ist klebrig und unprofessionell. Stattdessen sollten Endbenutzer zu einer Fehlerseite weitergeleitet werden, die das Aussehen und Verhalten der Website mit einer benutzerfreundlicheren Prosa, die die Situation beschreibt, behält. Die gute Nachricht ist, dass das Erstellen einer solchen benutzerdefinierten Fehlerseite ziemlich einfach ist. Dieses Tutorial beginnt mit einem Blick auf ASP. Die verschiedenen Fehlerseiten von NET. Anschließend wird gezeigt, wie die Webanwendung so konfiguriert wird, dass Benutzern eine benutzerdefinierte Fehlerseite angezeigt wird, wenn ein Fehler auftritt.

Untersuchen der drei Arten von Fehlerseiten

Wenn eine nicht behandelte Ausnahme in einer ASP.NET Anwendung auftritt, wird eine von drei Arten von Fehlerseiten angezeigt:

  • Die Seite "Ausnahmedetails gelber Bildschirm des Todesfehlers",
  • Die Seite "Laufzeitfehler Gelber Bildschirm des Todesfehlers" oder
  • Eine benutzerdefinierte Fehlerseite

Die Fehlerseite, mit der Entwickler am besten vertraut sind, ist der Ausnahmedetails-YSOD. Standardmäßig wird diese Seite benutzern angezeigt, die lokal besuchen, und ist daher die Seite, die angezeigt wird, wenn beim Testen der Website in der Entwicklungsumgebung ein Fehler auftritt. Wie der Name schon sagt, stellt der Ausnahmedetails-YSOD Details zur Ausnahme bereit – den Typ, die Nachricht und die Stapelüberwachung. Wenn die Ausnahme durch Code in der CodeBehind-Klasse Ihrer ASP.NET Seite ausgelöst wurde und die Anwendung für das Debuggen konfiguriert ist, zeigt der Ausnahmedetails-YSOD auch diese Codezeile (und einige Codezeilen darüber und darunter) an.

Abbildung 1 zeigt die Seite Ausnahmedetails YSOD. Notieren Sie sich die URL im Adressfenster des Browsers: http://localhost:62275/Genre.aspx?ID=foo. Erinnern Sie sich daran, dass auf der Genre.aspx Seite die Buchkritiken in einem bestimmten Genre aufgeführt sind. Es erfordert, dass der GenreId Wert (a uniqueidentifier) über die Abfragezeichenfolge übergeben wird. Die geeignete URL zum Anzeigen der Fiktionsüberprüfungen ist Genre.aspx?ID=7683ab5d-4589-4f03-a139-1c26044d0146z. B. . Wenn ein Nicht-Wertuniqueidentifier über die Abfragezeichenfolge (z. B. "foo") übergeben wird, wird eine Ausnahme ausgelöst.

Hinweis

Um diesen Fehler in der zum Download verfügbaren Demo-Webanwendung zu reproduzieren, können Sie entweder direkt besuchen Genre.aspx?ID=foo oder auf den Link "Laufzeitfehler generieren" in Default.aspxklicken.

Beachten Sie die in Abbildung 1 dargestellten Ausnahmeinformationen. Die Ausnahmemeldung "Konvertierung fehlgeschlagen beim Konvertieren von einer Zeichenfolge in uniqueidentifier" befindet sich oben auf der Seite. Der Typ der Ausnahme, System.Data.SqlClient.SqlException, wird ebenfalls aufgeführt. Es gibt auch die Stapelüberwachung.

Screenshot: Informationen zur Ausnahme.

Abbildung 1: Ausnahmedetails YSOD enthält Informationen zur Ausnahme
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Der andere Typ von YSOD ist der Laufzeitfehler YSOD, der in Abbildung 2 dargestellt ist. Das Laufzeitfehler-YSOD informiert den Besucher, dass ein Laufzeitfehler aufgetreten ist, enthält jedoch keine Informationen zu der ausgelösten Ausnahme. (Es enthält jedoch Anweisungen dazu, wie die Fehlerdetails durch Ändern der Web.config Datei angezeigt werden können, was teil dessen ist, was ein solches YSOD unprofessionell macht.)

Standardmäßig wird der Laufzeitfehler YSOD benutzern angezeigt, die remote (über http://www.yoursite.com) besuchen, wie die URL in der Adressleiste des Browsers in Abbildung 2 zeigt. http://httpruntime.web703.discountasp.net/Genre.aspx?ID=foo Die beiden verschiedenen YSOD-Bildschirme sind vorhanden, da Entwickler daran interessiert sind, die Fehlerdetails zu kennen, aber solche Informationen sollten nicht auf einer Livewebsite angezeigt werden, da sie potenzielle Sicherheitsrisiken oder andere vertrauliche Informationen für jeden, der Ihre Website besucht, offenlegen können.

Hinweis

Wenn Sie folgen und DiscountASP.NET als Webhost verwenden, werden Sie möglicherweise feststellen, dass die Laufzeitfehler-YSOD beim Besuch der Livewebsite nicht angezeigt wird. Dies liegt daran, dass DiscountASP.NET ihre Server so konfiguriert haben, dass sie standardmäßig den Ausnahmedetails-YSOD anzeigen. Die gute Nachricht ist, dass Sie dieses Standardverhalten überschreiben können, indem Sie Ihrer Web.config Datei einen <customErrors> Abschnitt hinzufügen. Im Abschnitt "Konfigurieren, welche Fehlerseite angezeigt wird" wird der <customErrors> Abschnitt ausführlich untersucht.

Screenshot, der zeigt, dass der Laufzeitfehler YSOD keine Fehlerdetails enthält.

Abbildung 2: Der Laufzeitfehler YSOD enthält keine Fehlerdetails.
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Der dritte Typ von Fehlerseite ist die benutzerdefinierte Fehlerseite, bei der es sich um eine von Ihnen erstellte Webseite handelt. Der Vorteil einer benutzerdefinierten Fehlerseite besteht darin, dass Sie die vollständige Kontrolle über die Informationen haben, die dem Benutzer zusammen mit dem Erscheinungsbild der Seite angezeigt werden. Die benutzerdefinierte Fehlerseite kann die gleichen master Seite und Formatvorlagen wie ihre anderen Seiten verwenden. Der Abschnitt "Verwenden einer benutzerdefinierten Fehlerseite" führt Sie durch das Erstellen einer benutzerdefinierten Fehlerseite und deren Konfiguration für die Anzeige im Falle einer nicht behandelten Ausnahme. Abbildung 3 enthält eine Schleichspitze dieser benutzerdefinierten Fehlerseite. Wie Sie sehen können, ist das Aussehen und Verhalten der Fehlerseite viel professioneller als die in den Abbildungen 1 und 2 gezeigten gelben Bildschirme des Todes.

Screenshot der benutzerdefinierten Fehlerseite, die Sie erstellen können, um ein maßgeschneidertes Aussehen und Verhalten zu bieten.

Abbildung 3: Eine benutzerdefinierte Fehlerseite bietet ein maßgeschneidertes Erscheinungsbild
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Nehmen Sie sich einen Moment Zeit, um die Adressleiste des Browsers in Abbildung 3 zu überprüfen. Beachten Sie, dass die Adressleiste die URL der benutzerdefinierten Fehlerseite (/ErrorPages/Oops.aspx) anzeigt. In den Abbildungen 1 und 2 sind die gelben Bildschirme des Todes auf derselben Seite dargestellt, von der der Fehler stammt (Genre.aspx). Die benutzerdefinierte Fehlerseite wird über den parameter querystring die URL der Seite übergeben, auf der der aspxerrorpath Fehler aufgetreten ist.

Konfigurieren der angezeigten Fehlerseite

Welche der drei möglichen Fehlerseiten angezeigt wird, basiert auf zwei Variablen:

  • Die Konfigurationsinformationen im <customErrors> Abschnitt und
  • Gibt an, ob der Benutzer die Website lokal oder remote besucht.

Der <customErrors> Abschnitt in Web.config enthält zwei Attribute, die sich darauf auswirken, welche Fehlerseite angezeigt wird: defaultRedirect und mode. Das defaultRedirect-Attribut ist optional. Falls angegeben, gibt er die URL der benutzerdefinierten Fehlerseite an und gibt an, dass die benutzerdefinierte Fehlerseite anstelle des Laufzeitfehler-YSOD angezeigt werden soll. Das mode Attribut ist erforderlich und akzeptiert einen von drei Werten: On, Offoder RemoteOnly. Diese Werte weisen das folgende Verhalten auf:

  • On – gibt an, dass die benutzerdefinierte Fehlerseite oder die Laufzeitfehler-YSOD allen Besuchern angezeigt wird, unabhängig davon, ob sie lokal oder remote sind.
  • Off – gibt an, dass das Ausnahmedetails-YSOD für alle Besucher angezeigt wird, unabhängig davon, ob sie lokal oder remote sind.
  • RemoteOnly – gibt an, dass die benutzerdefinierte Fehlerseite oder die Laufzeitfehler-YSOD Remotebesuchern angezeigt wird, während die Ausnahmedetails YSOD lokalen Besuchern angezeigt wird.

Sofern Sie nichts anderes angeben, verhält sich ASP.NET so, als hätten Sie das Mode-Attribut auf RemoteOnly festgelegt und keinen Wert angegeben defaultRedirect . Anders ausgedrückt: Das Standardverhalten besteht darin, dass der Ausnahmedetails-YSOD für lokale Besucher angezeigt wird, während der Laufzeitfehler-YSOD Remotebesuchern angezeigt wird. Sie können dieses Standardverhalten überschreiben, indem Sie einen <customErrors> Abschnitt zu Ihrer Webanwendung hinzufügen. Web.config file.

Verwenden einer benutzerdefinierten Fehlerseite

Jede Webanwendung sollte über eine benutzerdefinierte Fehlerseite verfügen. Es bietet eine professionellere Alternative zum Laufzeitfehler YSOD, es ist einfach zu erstellen, und die Konfiguration der Anwendung für die Verwendung der benutzerdefinierten Fehlerseite dauert nur wenige Augenblicke. Der erste Schritt besteht darin, die benutzerdefinierte Fehlerseite zu erstellen. Ich habe der Buchprüfungsanwendung einen neuen Ordner namens ErrorPages hinzugefügt und dieser eine neue ASP.NET Seite namens Oops.aspxhinzugefügt. Lassen Sie die Seite die gleiche master Seite wie die restlichen Seiten auf Ihrer Website verwenden, damit sie automatisch das gleiche Erscheinungsbild erbt.

Screenshot: Ordner

Abbildung 4: Erstellen einer benutzerdefinierten Fehlerseite

Als Nächstes müssen Sie einige Minuten damit verbringen, den Inhalt für die Fehlerseite zu erstellen. Ich habe eine ziemlich einfache benutzerdefinierte Fehlerseite mit einer Meldung erstellt, die angibt, dass ein unerwarteter Fehler aufgetreten ist, und einen Link zurück zur Homepage der Website.

Screenshot, der zeigt, wie Sie Ihre eigene benutzerdefinierte Fehlerseite entwerfen können.

Abbildung 5: Entwerfen ihrer benutzerdefinierten Fehlerseite
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Wenn die Fehlerseite abgeschlossen ist, konfigurieren Sie die Webanwendung so, dass anstelle des Laufzeitfehler-YSOD die benutzerdefinierte Fehlerseite verwendet wird. Dies wird erreicht, indem die URL der Fehlerseite im Attribut des <customErrors> Abschnitts defaultRedirect angegeben wird. Fügen Sie der Datei Ihrer Anwendung Web.config das folgende Markup hinzu:

<configuration>
    ...

    <system.web>
        <customErrors mode="RemoteOnly"
                      defaultRedirect="~/ErrorPages/Oops.aspx" />

        ...
    </system.web>
</configuration>

Mit dem obigen Markup wird die Anwendung so konfiguriert, dass die Ausnahmedetails YSOD für Benutzer angezeigt wird, die lokal besuchen, während die benutzerdefinierte Fehlerseite Oops.aspx für diese Benutzer verwendet wird, die remote besuchen. Um dies in Aktion zu sehen, stellen Sie Ihre Website in der Produktionsumgebung bereit, und besuchen Sie dann die Seite Genre.aspx auf der Livewebsite mit einem ungültigen Querystring-Wert. Die Seite mit benutzerdefinierten Fehlern sollte angezeigt werden (siehe Abbildung 3).

Um zu überprüfen, ob die benutzerdefinierte Fehlerseite nur Remotebenutzern angezeigt wird, besuchen Sie die Genre.aspx Seite mit einer ungültigen Abfragezeichenfolge aus der Entwicklungsumgebung. Der Ausnahmedetails-YSOD sollte weiterhin angezeigt werden (siehe Abbildung 1). Die RemoteOnly Einstellung stellt sicher, dass Benutzer, die die Website in der Produktionsumgebung besuchen, die benutzerdefinierte Fehlerseite sehen, während Entwickler, die lokal arbeiten, weiterhin die Details der Ausnahme sehen.

Benachrichtigen von Entwicklern und Protokollierungsfehlerdetails

Fehler, die in der Entwicklungsumgebung auftreten, wurden durch den Entwickler verursacht, der an ihrem Computer saß. Ihr werden die Informationen der Ausnahme im YSOD der Ausnahmedetails angezeigt, und sie weiß, welche Schritte sie ausgeführt hat, als der Fehler aufgetreten ist. Wenn jedoch in der Produktion ein Fehler auftritt, ist dem Entwickler nicht bekannt, dass ein Fehler aufgetreten ist, es sei denn, der Endbenutzer, der die Website besucht, nimmt sich die Zeit, den Fehler zu melden. Und selbst wenn der Benutzer alles gibt, um das Entwicklungsteam zu benachrichtigen, dass ein Fehler aufgetreten ist, ohne den Ausnahmetyp, die Nachricht und die Stapelverfolgung zu kennen, kann es schwierig sein, die Ursache des Fehlers zu diagnostizieren, geschweige denn zu beheben.

Aus diesen Gründen ist es von entscheidender Bedeutung, dass alle Fehler in der Produktionsumgebung in einem persistenten Speicher (z. B. einer Datenbank) protokolliert werden und dass die Entwickler über diesen Fehler benachrichtigt werden. Die benutzerdefinierte Fehlerseite scheint ein guter Ort für diese Protokollierung und Benachrichtigung zu sein. Leider hat die benutzerdefinierte Fehlerseite keinen Zugriff auf die Fehlerdetails und kann daher nicht zum Protokollieren dieser Informationen verwendet werden. Die gute Nachricht ist, dass es eine Reihe von Möglichkeiten gibt, die Fehlerdetails abzufangen und zu protokollieren, und die nächsten drei Tutorials untersuchen dieses Thema ausführlicher.

Verwenden verschiedener benutzerdefinierter Fehlerseiten für unterschiedliche HTTP-Fehlerstatus

Wenn eine Ausnahme von einer ASP.NET Seite ausgelöst wird und nicht behandelt wird, wird die Ausnahme bis zur ASP.NET Runtime verschoben, auf der die konfigurierte Fehlerseite angezeigt wird. Wenn eine Anforderung in die ASP.NET-Engine eingeht, aber aus irgendeinem Grund nicht verarbeitet werden kann - möglicherweise wird die angeforderte Datei nicht gefunden oder Leseberechtigungen für die Datei deaktiviert -, löst die ASP.NET-Engine einen aus HttpException. Diese Ausnahme, wie Ausnahmen, die von ASP.NET Seiten ausgelöst werden, blasen bis zur Laufzeit, wodurch die entsprechende Fehlerseite angezeigt wird.

Dies bedeutet für die Webanwendung in der Produktion: Wenn ein Benutzer eine Seite anfordert, die nicht gefunden wird, wird die benutzerdefinierte Fehlerseite angezeigt. Abbildung 6 zeigt ein solches Beispiel. Da es sich bei der Anforderung um eine nicht vorhandene Seite handelt (NoSuchPage.aspx), wird eine HttpException ausgelöst, und die benutzerdefinierte Fehlerseite wird angezeigt (beachten Sie den Verweis auf NoSuchPage.aspx im aspxerrorpath querystring-Parameter).

Screenshot der angezeigten konfigurierten FehlerseiteAbbildung 6: Die ASP.NET Runtime zeigt die Seite "Konfigurierte Fehler als Reaktion auf eine ungültige Anforderung" an.
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Standardmäßig führen alle Fehlertypen dazu, dass dieselbe benutzerdefinierte Fehlerseite angezeigt wird. Sie können jedoch eine andere benutzerdefinierte Fehlerseite für einen bestimmten HTTP-status Code angeben, indem Sie untergeordnete Elemente innerhalb des Abschnitts <customErrors> verwenden<error>. Wenn beispielsweise eine andere Fehlerseite angezeigt wird, wenn eine Seite nicht gefunden wurde, die den HTTP-status Code 404 aufweist, aktualisieren Sie den <customErrors> Abschnitt so, dass er das folgende Markup enthält:

<customErrors mode="RemoteOnly" defaultRedirect="~/ErrorPages/Oops.aspx">
    <error statusCode="404" redirect="~/ErrorPages/404.aspx" />
</customErrors>

Mit dieser Änderung wird ein Benutzer, der remote eine ASP.NET Ressource anfordert, die nicht vorhanden ist, zur benutzerdefinierten Fehlerseite anstelle von Oops.aspxumgeleitet404.aspx. Wie Abbildung 7 veranschaulicht, kann die 404.aspx Seite eine spezifischere Nachricht als die allgemeine benutzerdefinierte Fehlerseite enthalten.

Hinweis

Informationen zum Erstellen effektiver 404-Fehlerseiten finden Sie unter "404 Fehlerseiten", "One More Time ".

Screenshot der angezeigten geteerten NachrichtAbbildung 7: Auf der Seite "Benutzerdefinierte 404-Fehler" wird eine gezieltere Nachricht angezeigt als Oops.aspx
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Da Sie wissen, dass die 404.aspx Seite nur erreicht wird, wenn der Benutzer eine Anforderung für eine Seite stellt, die nicht gefunden wurde, können Sie diese benutzerdefinierte Fehlerseite so erweitern, dass sie Funktionen enthält, die dem Benutzer helfen, diese bestimmte Art von Fehler zu beheben. Beispielsweise könnten Sie eine Datenbanktabelle erstellen, die bekannte schlechte URLs guten URLs zuordnet, und dann eine Abfrage für diese 404.aspx Tabelle ausführen lassen und Seiten vorschlagen, die der Benutzer möglicherweise erreichen möchte.

Hinweis

Die benutzerdefinierte Fehlerseite wird nur angezeigt, wenn eine Anforderung an eine Ressource gestellt wird, die vom ASP.NET-Engine behandelt wird. Wie im Tutorial Grundlegende Unterschiede zwischen IIS und dem ASP.NET Development Server erläutert, verarbeitet der Webserver möglicherweise bestimmte Anforderungen selbst. Standardmäßig verarbeitet der IIS-Webserver Anforderungen für statische Inhalte wie Bilder und HTML-Dateien, ohne die ASP.NET-Engine zu aufrufen. Wenn der Benutzer daher eine nicht vorhandene Imagedatei anfordert, erhält er anstelle von ASP die Standardfehlermeldung 404 von IIS zurück. NET's konfigurierte Fehlerseite.

Zusammenfassung

Wenn eine nicht behandelte Ausnahme in einer ASP.NET Anwendung auftritt, wird dem Benutzer eine von drei Fehlerseiten angezeigt: der gelbe Bildschirm der Ausnahmedetails des Todes; der gelbe Bildschirm des Todes bei Laufzeitfehlern; oder eine benutzerdefinierte Fehlerseite. Welche Fehlerseite angezeigt wird, hängt von der Konfiguration der Anwendung <customErrors> ab und davon, ob der Benutzer lokal oder remote besucht. Das Standardverhalten besteht darin, den Ausnahmedetails-YSOD für lokale Besucher und den Laufzeitfehler YSOD für Remotebesucher anzuzeigen.

Während der Laufzeitfehler-YSOD potenziell vertrauliche Fehlerinformationen des Benutzers, der die Website besucht, ausblendet, bricht er das Erscheinungsbild Ihrer Website und sorgt dafür, dass Ihre Anwendung fehlerhaft aussieht. Ein besserer Ansatz besteht darin, eine benutzerdefinierte Fehlerseite zu verwenden, was das Erstellen und Entwerfen der benutzerdefinierten Fehlerseite und die Angabe der URL im Attribut des <customErrors> Abschnitts defaultRedirect umfasst. Sie können sogar mehrere benutzerdefinierte Fehlerseiten für unterschiedliche HTTP-Fehlerstatus haben.

Die benutzerdefinierte Fehlerseite ist der erste Schritt in einer umfassenden Fehlerbehandlungsstrategie für eine Website in der Produktion. Das Warnen des Entwicklers über den Fehler und die Protokollierung seiner Details sind ebenfalls wichtige Schritte. In den nächsten drei Tutorials werden Techniken für Fehlerbenachrichtigungen und -protokollierungen untersucht.

Viel Spaß beim Programmieren!

Weitere Informationen

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

ZurückWeiter