Anzeigen einer benutzerdefinierten Fehlerseite (VB)

von Scott Mitchell

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

Einführung

In einer perfekten Welt wären keine Laufzeitfehler vorhanden. Programmierer würden Code ohne jegliche Fehler und mit robuster Benutzereingabevalidierung schreiben, und externe Ressourcen wie Datenbankserver und E-Mail-Server würden niemals offline gehen. Natürlich sind in Wirklichkeit Fehler unvermeidlich. Die Klassen im .NET Framework signalisieren einen Fehler, indem eine Ausnahme ausgelöst wird. Das Aufrufen der Open-Methode eines SqlConnection-Objekts stellt beispielsweise eine Verbindung mit der Datenbank her, die durch eine Verbindungszeichenfolge angegeben wird. Wenn die Datenbank jedoch ausgefallen ist oder die Anmeldeinformationen in der Verbindungszeichenfolge ungültig sind, wirft die Open-Methode ein SqlException aus. Ausnahmen können mithilfe von Try/Catch/Finally Blöcken behandelt werden. Wenn Code innerhalb eines Try Blocks eine Ausnahme auslöst, wird das Steuerelement 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, durchsucht die Ausnahme den Aufrufstapel bei der Suche nach Try/Catch/Finally Blöcken.

Wenn die Ausnahme bis zur ASP.NET Laufzeit ohne Behandlung übergeht, wird das Ereignis der HttpApplication KlasseError ausgelöst und die konfigurierte Fehlerseite angezeigt. Standardmäßig zeigt ASP.NET eine Fehlerseite an, die liebevoll als gelber Bildschirm des Todes (YSOD) bezeichnet wird. Es gibt zwei Versionen von YSOD: eine zeigt die Ausnahmedetails, eine Stapelablaufverfolgung und andere Informationen, die für Entwickler beim Debuggen der Anwendung hilfreich sind (siehe Abbildung 1); die andere gibt einfach an, dass ein Laufzeitfehler aufgetreten ist (siehe Abbildung 2).

Die Ausnahmedetails YSOD sind für Entwickler zum Debuggen der Anwendung sehr hilfreich, aber ein YSOD Endbenutzern zu zeigen ist geschmacklos und unprofessionell. Stattdessen sollten Endbenutzer auf eine Fehlerseite weitergeleitet werden, die das Erscheinungsbild der Website mit benutzerfreundlicherem Text beschreibt, der die Situation erläutert. Die gute Nachricht ist, dass das Erstellen einer solchen benutzerdefinierten Fehlerseite ziemlich einfach ist. Dieses Tutorial beginnt mit einem Blick auf die verschiedenen Fehlerseiten von ASP.NET. Anschließend wird gezeigt, wie Sie die Webanwendung so konfigurieren, dass Benutzern eine benutzerdefinierte Fehlerseite im Gesicht eines Fehlers angezeigt wird.

Untersuchen der drei Arten von Fehlerseiten

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

• Die Fehlerseite "Yellow Screen of Death" mit Ausnahmeinformationen.
• Die Laufzeitfehler-Gelbschirm-des-Todes-Seite oder
• Eine benutzerdefinierte Fehlerseite

Die Fehlerseite, mit der Entwickler am meisten vertraut sind, ist die Ausnahmedetails YSOD. Standardmäßig wird diese Seite für Benutzer angezeigt, die lokal besuchen und daher die Seite ist, die angezeigt wird, wenn beim Testen der Website in der Entwicklungsumgebung ein Fehler auftritt. Wie der Name schon sagt, enthält das Ausnahmedetail YSOD Details zur Ausnahme – wie den Typ, die Nachricht und die Stapelablaufverfolgung. Wenn die Ausnahme durch Code in der Code-Behind-Klasse Ihrer ASP.NET-Seite ausgelöst wurde und die Anwendung für die Fehlersuche konfiguriert ist, zeigt die YSOD-Ausnahmedetailsseite auch diese Codezeile (sowie einige Codezeilen darüber und darunter) an.

Abbildung 1 zeigt die Seite "Ausnahmedetails YSOD". Beachten Sie die URL im Adressfenster des Browsers: http://localhost:62275/Genre.aspx?ID=foo. Erinnern Sie sich daran, dass die Genre.aspx Seite die Buchrezensionen in einem bestimmten Genre auflistet. Es setzt voraus, dass der GenreId Wert (ein uniqueidentifier) über die Abfragezeichenfolge übergeben wird, z. B. um die passende URL anzusehen, ist die richtige URL für die Fiktion Bewertungen Genre.aspx?ID=7683ab5d-4589-4f03-a139-1c26044d0146. Wenn ein Nicht-Wertuniqueidentifier über die Abfragezeichenfolge (z. B. "foo") übergeben wird, wird eine Ausnahme ausgelöst.

Beachten Sie die Ausnahmeinformationen, die in Abbildung 1 dargestellt werden. Die Ausnahmemeldung "Fehler bei der Konvertierung von einer Zeichenfolge in einen Uniqueidentifier" ist oben auf der Seite vorhanden. Der Typ der Ausnahme, System.Data.SqlClient.SqlExceptionwird ebenfalls aufgeführt. Es gibt auch einen Stack-Trace.

Abbildung 1: Die Ausnahmedetails YSOD enthalten Informationen über die Ausnahme
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Der andere YSOD-Typ ist der Laufzeitfehler YSOD und ist in Abbildung 2 dargestellt. Der Laufzeitfehler YSOD informiert den Besucher darüber, dass ein Laufzeitfehler aufgetreten ist, enthält jedoch keine Informationen über die ausgelöste Ausnahme. (Es enthält jedoch Anweisungen dazu, wie die Fehlerdetails durch Ändern der Web.config-Datei angezeigt werden können, was dazu beiträgt, dass ein solcher YSOD unprofessionell wirkt.)

Standardmäßig wird Benutzern, die remote zugreifen (durch http://www.yoursite.com), der Laufzeitfehler YSOD angezeigt, wie in der URL in der Adressleiste des Browsers in Abbildung 2 dargestellt. 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 alle Benutzer, die Ihre Website besuchen, 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 der 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 dieselbe Gestaltungsvorlage und -formatvorlagen wie ihre anderen Seiten verwenden. Der Abschnitt "Verwenden einer benutzerdefinierten Fehlerseite" durchläuft das Erstellen einer benutzerdefinierten Fehlerseite und das Konfigurieren der Seite, die im Falle einer unbehandelten Ausnahme angezeigt werden soll. Abbildung 3 bietet einen Einblick in diese benutzerdefinierte Fehlerseite. Wie Sie sehen können, ist das Aussehen und Verhalten der Fehlerseite viel professioneller als eines der gelben Bildschirme des Todes in abbildung 1 und 2.

Abbildung 3: Eine benutzerdefinierte Fehlerseite bietet ein maßgeschneidertes Aussehen und Verhalten.
(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 prüfen. Beachten Sie, dass in der Adressleiste die URL der benutzerdefinierten Fehlerseite (/ErrorPages/Oops.aspx) angezeigt wird. In den Abbildungen 1 und 2 werden die gelben Bildschirme des Todes auf derselben Seite angezeigt, von der der Fehler stammt (Genre.aspx). Die benutzerdefinierte Fehlerseite wird die URL der Seite übergeben, auf der der Fehler über den aspxerrorpath Abfragezeichenfolgenparameter aufgetreten ist.

Konfigurieren, Welche Fehlerseite Angezeigt Wird

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

• Die Konfigurationsinformationen im <customErrors> Abschnitt und
• Unabhängig davon, ob der Benutzer die Website lokal oder remote besucht.

Der <customErrors> Abschnitt in Web.config verfügt über zwei Attribute, die sich auf die angezeigte Fehlerseite auswirken: defaultRedirect und mode. Das defaultRedirect-Attribut ist optional. Wenn angegeben, gibt sie die URL der benutzerdefinierten Fehlerseite an und gibt an, dass die benutzerdefinierte Fehlerseite anstelle des Laufzeitfehlers 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 die Ausnahme-Details YSOD allen Besuchern angezeigt werden, unabhängig davon, ob sie sich lokal oder entfernt befinden.
• RemoteOnly - gibt an, dass die benutzerdefinierte Fehlerseite oder die Laufzeitfehler-YSOD entfernten Besuchern angezeigt wird, während die Ausnahmedetails YSOD lokalen Besuchern angezeigt wird.

Sofern Sie nichts anderes angeben, verhält sich ASP.NET, als hätten Sie das Modus-Attribut auf RemoteOnly gesetzt und keinen defaultRedirect-Wert festgelegt. Mit anderen Worten: Das Standardverhalten besteht darin, dass die Ausnahmedetails YSOD lokalen Besuchern angezeigt wird, während dem Laufzeitfehler YSOD Remotebesuchern angezeigt werden. Sie können dieses Standardverhalten außer Kraft setzen, indem Sie einen <customErrors> Abschnitt zu den Webanwendungen hinzufügen. Web.config file.

Verwenden einer benutzerdefinierten Fehlerseite

Jede Webanwendung sollte über eine benutzerdefinierte Fehlerseite verfügen. Es bietet eine professionellere Alternative zum Runtime Error YSOD, es ist einfach zu erstellen und die Anwendung für die Verwendung der benutzerdefinierten Fehlerseite zu konfigurieren, dauert nur ein paar Minuten. Der erste Schritt besteht darin, die benutzerdefinierte Fehlerseite zu erstellen. Ich habe der Anwendung "Buchrezensionen" einen neuen Ordner namens ErrorPages hinzugefügt und dieser eine neue ASP.NET Seite mit dem Namen Oops.aspxhinzugefügt. Verwenden Sie die gleiche Masterseite wie die restlichen Seiten Ihrer Website, damit sie automatisch das gleiche Erscheinungsbild erbt.

Abbildung 4: Erstellen einer benutzerdefinierten Fehlerseite

Als Nächstes verbringen Sie ein paar Minuten mit dem Erstellen des Inhalts für die Fehlerseite. Ich habe eine ziemlich einfache benutzerdefinierte Fehlerseite mit einer Meldung erstellt, die angibt, dass ein unerwarteter Fehler und ein Link zurück zur Homepage der Website aufgetreten ist.

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

Um die benutzerdefinierte Fehlerseite anstelle des Laufzeitfehlers YSOD zu verwenden, konfigurieren Sie die Webanwendung nach Fertigstellung der Fehlerseite. Dazu wird die URL der Fehlerseite im Attribut des <customErrors> Abschnitts defaultRedirect angegeben. 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>

Im obigen Markup wird die Anwendung so konfiguriert, dass die Ausnahmedetailseite YSOD für Benutzer, die das System lokal besuchen, angezeigt wird, während für Benutzer, die das System remote besuchen, die benutzerdefinierte Fehlerseite Oops.aspx 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 Live-Website mit einem ungültigen Abfragezeichenfolgenwert. 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 Fehlerdetails des 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 Protokollieren von Fehlerdetails

Fehler, die in der Entwicklungsumgebung auftreten, wurden durch den Entwickler verursacht, der auf ihrem Computer sitzt. Ihr werden die Informationen der Ausnahme in den Ausnahmedetails YSOD angezeigt, und sie weiß, welche Schritte sie ausführte, als der Fehler auftrat. Wenn jedoch ein Fehler in der Produktion auftritt, ist dem Entwickler nicht bekannt, dass ein Fehler aufgetreten ist, es sei denn, der Endbenutzer, der die Website besucht, benötigt die Zeit, um den Fehler zu melden. Und selbst wenn der Benutzer sich die Mühe macht, das Entwicklungsteam darauf hinzuweisen, dass ein Fehler aufgetreten ist, kann es ohne Kenntnis des Ausnahmetyps, der Meldung und der Stapelablaufverfolgung schwierig sein, die Ursache des Fehlers zu diagnostizieren, geschweige denn zu beheben.

Aus diesen Gründen ist es von größter Bedeutung, dass jeder Fehler in der Produktionsumgebung bei einem beständigen Speicher (z. B. einer Datenbank) protokolliert wird und dass die Entwickler auf diesen Fehler hingewiesen werden. Die benutzerdefinierte Fehlerseite scheint möglicherweise 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 verwendet werden, um diese Informationen zu protokollieren. Die gute Nachricht ist, dass es eine Reihe von Möglichkeiten gibt, die Fehlerdetails abzufangen und sie zu protokollieren, und die nächsten drei Lernprogramme erkunden 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-Laufzeit weitergeleitet, die dann die konfigurierte Fehlerseite anzeigt. Wenn eine Anforderung in die ASP.NET-Engine gelangt, aber aus irgendeinem Grund nicht verarbeitet werden kann - möglicherweise weil die angeforderte Datei nicht gefunden wurde oder die Leseberechtigungen für die Datei deaktiviert wurden - dann löst die ASP.NET-Engine ein HttpException aus. Diese Ausnahme wird, wie bei Ausnahmen von ASP.NET-Seiten, an die Laufzeit weitergeleitet und führt dazu, dass 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 sich die Anforderung auf eine nicht vorhandene Seite (NoSuchPage.aspx) bezieht, wird eine HttpException ausgelöst, und die benutzerdefinierte Fehlerseite wird angezeigt (beachten Sie den Verweis NoSuchPage.aspx im aspxerrorpath Abfragezeichenfolgenparameter).

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 werden alle Arten von Fehlern dazu führen, dass dieselbe benutzerdefinierte Fehlerseite angezeigt wird. Sie können jedoch eine andere benutzerdefinierte Fehlerseite für einen bestimmten HTTP-Statuscode angeben, indem Sie <error> untergeordnete Elemente im <customErrors> Abschnitt verwenden. Wenn beispielsweise eine andere Fehlerseite angezeigt wird, wenn ein Fehler auf einer Seite nicht gefunden wurde, der einen HTTP-Statuscode von 404 aufweist, aktualisieren Sie den <customErrors> Abschnitt so, dass es das folgende Markup enthält:

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

Mit dieser Änderung wird, wenn ein Benutzer, der remote besucht, eine ASP.NET Ressource anfordert, die nicht vorhanden ist, an die 404.aspx benutzerdefinierte Fehlerseite anstatt Oops.aspxumgeleitet. Wie in Abbildung 7 dargestellt, kann die 404.aspx Seite eine spezifischere Meldung enthalten als die allgemeine benutzerdefinierte Fehlerseite.

Abbildung 7: Auf der benutzerdefinierten 404-Fehlerseite wird eine gezieltere Meldung 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 vorgibt, die nicht gefunden wurde, können Sie diese benutzerdefinierte Fehlerseite verbessern, um Funktionen einzuschließen, um dem Benutzer bei der Behebung dieses bestimmten Fehlertyps zu helfen. Sie können z. B. eine Datenbanktabelle erstellen, die bekannte fehlerhafte URLs guten URLs zuordnet, und dann die 404.aspx benutzerdefinierte Fehlerseite eine Abfrage für diese Tabelle ausführen lassen und Seiten vorschlagen, die der Benutzer möglicherweise erreichen möchte.

Zusammenfassung

Wenn eine unbehandelte Ausnahme in einer ASP.NET-Anwendung auftritt, wird dem Benutzer eine von drei Fehlerseiten angezeigt: der Gelbe Ausnahmebildschirm des Todes, der Gelbe Laufzeitfehlerbildschirm des Todes oder eine benutzerdefinierte Fehlerseite. Welche Fehlerseite angezeigt wird, hängt von der Konfiguration der <customErrors> Anwendung ab und davon, ob der Benutzer lokal oder remote besucht. Das Standardverhalten besteht darin, die Ausnahmedetails YSOD lokalen Besuchern und dem Laufzeitfehler YSOD für Remotebesucher anzuzeigen.

Während der Laufzeitfehler YSOD potenziell vertrauliche Fehlerinformationen vor dem Benutzer, der die Website besucht, ausblendet, stört er das Erscheinungsbild und die Benutzbarkeit Ihrer Website und lässt Ihre Anwendung fehlerhaft erscheinen. Ein besserer Ansatz besteht darin, eine benutzerdefinierte Fehlerseite zu verwenden, die das Erstellen und Entwerfen der benutzerdefinierten Fehlerseite und die Angabe der URL im Attribut des <customErrors> Abschnitts defaultRedirect beinhaltet. 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. Die Warnung des Entwicklers des Fehlers und die Protokollierung seiner Details sind ebenfalls wichtige Schritte. In den nächsten drei Lernprogrammen werden Techniken zur Fehlerbenachrichtigung und Protokollierung erläutert.

Glückliche Programmierung!

Weiterführende Lektüre

Weitere Informationen zu den in diesem Lernprogramm erläuterten 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 von benutzerdefinierten Fehlerseiten in ASP.NET