Anzeigen einer benutzerdefinierten Fehlerseite (C#)

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.

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.

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.

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.

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.

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 recht einfache benutzerdefinierte Fehlerseite mit einer Meldung erstellt, die angibt, dass ein unerwarteter Fehler aufgetreten ist, und einen Link zurück zur Homepage der Website.

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

Wenn die Fehlerseite abgeschlossen ist, konfigurieren Sie die Webanwendung so, dass die benutzerdefinierte Fehlerseite anstelle des Laufzeitfehler-YSOD verwendet wird. Dazu geben Sie die URL der Fehlerseite im -Attribut des <customErrors> Abschnitts defaultRedirect an. 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 benutzerseitige Remotezugriffe verwendet wird. 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 Benutzerdefinierte Fehlerseite 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. Die Ausnahmedetails YSOD sollten 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 sitzt. Ihr werden die Informationen zur Ausnahme im Ausnahmedetails-YSOD 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. Selbst wenn der Benutzer das Entwicklungsteam über einen Fehler informiert, ohne den Ausnahmetyp, die Meldung und die Stapelüberwachung zu kennen, kann es schwierig sein, die Fehlerursache zu diagnostizieren, geschweige denn zu beheben.

Aus diesen Gründen ist es von entscheidender Bedeutung, dass jeder Fehler in der Produktionsumgebung in einem persistenten Speicher (z. B. einer Datenbank) protokolliert wird 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 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 wurde die angeforderte Datei nicht gefunden oder Leseberechtigungen für die Datei deaktiviert), dann löst die ASP.NET-Engine einen aus HttpException. Diese Ausnahme, wie Ausnahmen, die von ASP.NET Seiten ausgelöst werden, wird bis zur Laufzeit ausgegeben, wodurch die entsprechende Fehlerseite angezeigt wird.

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

Abbildung 6: Die ASP.NET Runtime zeigt die Seite "Konfigurierter 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 wird, 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 Meldung als die allgemeine benutzerdefinierte Fehlerseite enthalten.

Abbildung 7: Die benutzerdefinierte 404-Fehlerseite zeigt eine gezieltere Meldung 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 sendet, die nicht gefunden wurde, können Sie diese benutzerdefinierte Fehlerseite so erweitern, dass sie Funktionen enthält, die dem Benutzer bei der Behebung dieses bestimmten Fehlertyps helfen. Sie könnten beispielsweise eine Datenbanktabelle erstellen, die bekannte ungültige URLs guten URLs zuordnet, und dann auf der 404.aspx benutzerdefinierten Fehlerseite eine Abfrage für diese Tabelle ausführen und Seiten vorschlagen, die der Benutzer möglicherweise erreichen möchte.

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; laufzeitfehler gelber Bildschirm des Todes; 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, lokalen Besuchern die Ausnahmedetails YSOD und remote besuchern den Laufzeitfehler YSOD anzuzeigen.

Während der Laufzeitfehler-YSOD potenziell vertrauliche Fehlerinformationen vor dem Benutzer ausblendet, der die Website besucht, bricht es das Erscheinungsbild Ihrer Website und sorgt dafür, dass Ihre Anwendung fehlerhaft aussieht. Ein besserer Ansatz ist die Verwendung einer benutzerdefinierten Fehlerseite, die das Erstellen und Entwerfen der benutzerdefinierten Fehlerseite und die Angabe ihrer 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 -protokollierung erläutert.

Viel Spaß beim Programmieren!

Weitere Informationen

Weitere Informationen zu den in diesem Tutorial behandelten Themen finden Sie in den folgenden Ressourcen:

• Fehlerseiten, einmal mehr
• Entwurfsrichtlinien für Ausnahmen
• Benutzerfreundliche Fehlerseiten
• Behandeln und Auslösen von Ausnahmen
• Ordnungsgemäße Verwendung benutzerdefinierter Fehlerseiten in ASP.NET
• Übersicht über die ASP.NET-Ablaufverfolgung