Benutzerdefinierte Fehlerbehandlung / -seiten in ASP.NET

Die strukturierte Fehlerbehandlung (Exception Handling) ist ein wesentlicher Bestandteil der Common Language Runtime. Mit dieser Art der Fehlerbehandlung ist es möglich, auf eine einfache und elegante Art und Weise erzeugte Fehler zu behandeln. Da die Fehlerbehandlung ein Bestandteil der CLR ist, wird diese natürlich auch in ASP.NET - Anwendungen unterstützt. Wenn in einer ASP.NET Seite ein Laufzeitfehler erzeugt wird, so wird eine Fehlerseite von ASP.NET ausgegeben, die eine Beschreibung und die Zeile des Fehlers enthält.

Diese genaue Fehlerbeschreibung ist während der Entwicklung ein wichtiger und informativer Bericht, den man als Entwickler nicht mehr vermissen möchte. Aber spätestens nach dem letzten Testdurchlauf werden diese Fehlerseiten aus der Sicht des Kunden sehr schnell unbeliebt und die ASP.NET - Applikation kann u.U. dadurch unprofessionell wirken. Andererseits möchte man als Entwickler die genaue Fehlerbeschreibung auswerten und beheben können. Es ist sinnvoll und meiner Meinung auch notwendig etwas zu konstruieren, das solche Fehler nicht direkt als Fehlerseite zum Kunden sendet, sondern eine eigene Fehlerseite aufruft, die ein etwas kundenfreundlichers Design besitzt. Vielleicht gelingt es auch den Fehler in irgendeiner schönen Art zu überspielen, sodass der Kunde den Fehler gar nicht bemerkt. Die Fehlerinformation soll aber nicht verloren gehen und müssen es auch nicht. Man kann die Fehlermeldungen z.B. in das EventLog eintragen oder als Textdatei, eMail,... weitergeben.

Was wir jetzt machen müssen ist eine fehlerbehaftete ASP.NET - Seite zu erstellen. Erzeugen wir dazu in VS.NET eine WebForm mit dem Namen WebForm1.aspx. Der Quellcode sollte ähnlich wie unten dargestellt aussehen.

<%@ Page Language="vb" AutoEventWireup="false" Codebehind="WebForm1.aspx.vb" Inherits="artikel001.WebForm1"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
  <title>WebForm1</title>
  <meta name="GENERATOR" content="Microsoft Visual Studio.NET 7.0">
  <meta name="CODE_LANGUAGE" content="Visual Basic 7.0">
  <meta name="vs_defaultClientScript" content="JavaScript">
  <meta name="vs_targetSchema" content="http://schemas.microsoft.com/intellisense/ie5">
</HEAD>
<body MS_POSITIONING="GridLayout">
  <form id="Form1" method="post" runat="server">
   <INPUT id="btnErr" style="Z-INDEX: 101; LEFT: 292px; POSITION: absolute; TOP: 136px" type="button"

value="Erzeuge Fehler ... ;-)" name="btnErr" runat="server">
</form>
</body>
</HTML>

Eigentlich nichts besonderes. Einfach ein Button in die WebForm einfügen - fertig. Den Fehler erzeugen wir im Code-Behind WebForm.aspx.vb

Public Class WebForm1
Inherits System.Web.UI.Page
Protected WithEvents btnErr As System.Web.UI.HtmlControls.HtmlInputButton

#Region " Vom Web Form Designer generierter Code "

'Dieser Aufruf ist für den Web Form-Designer erforderlich.
<System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent()

End Sub

    Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init
        'CODEGEN: Diese Methode ist für den Web Form-Designer erforderlich
        'Verwenden Sie nicht den Code-Editor zur Bearbeitung.
        InitializeComponent()
    End Sub

#End Region

    Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        ' Hier Benutzercode zur Seiteninitialisierung einfügen
    End Sub

    Private Sub btnErr_ServerClick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnErr.ServerClick
        'Hier wird zu einer nicht vorhandenen aspx-Seite weitergeleitet
        Response.Redirect("notHere.aspx")
    End Sub
End Class

Wenn man nun die Seite im Browser aufruft, sieht man in unserem Beispiel einen Button mit den Text "Erzeuge Fehler ;-)".

Klickt man jetzt auf den Button, der einen Fehler erzeugt, so erhält man den Fehler - Die Ressource kann nicht gefunden werden. Aber sehen wir uns das im untern Bild mal genauer an.

Naja, für den Kunden ist das Layout nicht gerade aufregend und die Information für Ihn nonsense. Eine der leichtesten Übungen ist das nachkonfigurieren der Standardkonfiguration in der Web.Config Datei. Rufen Sie hierzu die Web.Config Datei auf.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
    <compilation defaultLanguage="vb" debug="true" />
    <customErrors mode="RemoteOnly" />
    <authentication mode="Windows" />
    <authorization>
        <allow users="*" />
    </authorization>
    <trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
    <sessionState
            mode="InProc"
            stateConnectionString="tcpip=127.0.0.1:42424"
            sqlConnectionString="data source=127.0.0.1;user id=sa;password="
            cookieless="false"
            timeout="20"
    />
    <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
</system.web>
</configuration>

In dieser Datei interessiert und das customErrors - Tag

<customErrors mode="RemoteOnly" />

Hier können Sie drei verschiedene Moden aktivieren. Legen Sie customErrors mode="On" oder "RemoteOnly" fest, um benutzerdefinierte Fehlermeldungen zu aktivieren, "Off", um sie zu deaktivieren. Des weiteren kann man <error>-Tags für jeden Fehler hinzufügen, der behandelt werden soll.

Als erstes soll eine beliebige Seite, die einen Fehler erzeugt zu einer benutzerdefinierter Fehlerseite weitergeleitet werden. Dazu verändern wir das customErrors-Tag:

<customErrors defaultRedirect="fehler.htm" mode="On" />

Erzeugen Sie in Ihrem Projekt noch eine fehler.htm, die einen Text ausgibt. Wenn Sie die Anwendung jetzt neu erstellen und auf den "Erzeuge Fehler ;-)" - Button drücken, werden Sie zu der fehler.htm weitergeleitet.

Diesen Fehler werden wir zwar im LogFile des IIS sehen, aber es gibt natürlich auch noch andere Laufzeitfehler, die im LogFile des IIS nicht zu finden sind. Das Problem für den Entwickler ist es, dass keine Fehlerinformation mehr ersichtlich ist. Hier ist zwar ein Fehler passiert, darum der Redirect, aber was für ein Fehler ? Hier sollt man alternative aber sinnvolle Programme oder Methoden finden, die diese Fehlermeldungen archivieren oder speichern, verschicken, ...

Der EventLog ist ein sinnvoller Container für die Aufnahme von Fehlermeldungen. Was benötigen wir ? Eine Anwendungsübergreifende Datei - die Global.asax und ein sinnvoller Event.

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)

' Wird ausgelöst, wenn ein Fehler auftritt.
EventLog.WriteEntry("Application", Server.GetLastError.ToString)

End Sub

Der Eintrag in das Anwendungs-EventLog enthält nun die komplette Fehlerbeschreibung.

Die Beschreibung der Ereigniskennung ( 0 ) in ( Application ) wurde nicht gefunden. Der lokale Computer verfügt nicht über die zum Anzeigen der Meldungen von einem Remotecomputer erforderlichen Registrierungsinformationen oder DLL-Meldungsdateien. Möglicherweise müssen Sie das Flag /AUXSOURCE= zum Ermitteln der Beschreibung verwenden. Weitere Informationen stehen in Hilfe und Support. Ereignisinformationen: System.Web.HttpException: Eine Ausnahme vom Typ System.Web.HttpException wurde ausgelöst. ---> System.IO.FileNotFoundException: c:inetpubwwwrootartikel001 otHere.aspx

at System.Web.UI.TemplateParser.GetParserCacheItem()

at System.Web.UI.TemplateControlParser.CompileAndGetParserCacheItem(String virtualPath, String inputFile, HttpContext context)

at System.Web.UI.TemplateControlParser.GetCompiledInstance(String virtualPath, String inputFile, HttpContext context)

at System.Web.UI.PageParser.GetCompiledPageInstance(String virtualPath, String inputFile, HttpContext context)

at System.Web.UI.PageHandlerFactory.GetHandler(HttpContext context, String requestType, String url, String path)

at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, String path, String pathTranslated, Boolean useAppConfig)

--- Ende der internen Ausnahmestapelüberwachung ---

at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, String path, String pathTranslated, Boolean useAppConfig)

at System.Web.MapHandlerExecutionStep.Execute()

at System.Web.HttpApplication.ExecuteStep(IExecutionStep step,

Hier kann der Entwickler wieder ansetzten und den Fehler korrigieren ohne dass der Kunde eine häßliche Fehlerseite bekommt.