ASP-Fehlerbehandlung unter IIS5
Geschrieben von: Christoph Wille Mit IIS4 waren die Möglichkeiten der Fehlerbehandlung nur eingeschränkt vorhanden - entweder man ließ den Fehler geschehen, oder zeigte dem Benutzer eine kurze Textmeldung an (über die Einstellung Home Directory/Configuration/App Debugging) - und die dritte Variante war dann auch schon On Error Resume Next, um die Fehler gänzlich zu unterdrücken. An eine zentrale Fehlerbehandlungsseite war nicht zu denken, da Fehler nicht von einer Seite zu einer anderen weitergereicht werden konnten - das VBScript Err Objekt konnte nicht einmal von Funktion zu Funktion weitergereicht werden. Unter IIS5 gibt es jetzt die Möglichkeit, von ASP ausgelöste Fehler zentral in einer Datei abzuhandlen. Der Schlüssel dazu ist der HTTP Status Code 500.100, den man auf eine eigene Fehlerbehandlungsseite einmappen kann. Die Default Website hat bereits eine Fehlerbehandlungsseite: 500-100.asp, die im Verzeichnis %SystemRoot%\help\iishelp\common liegt. Alle anderen Websites haben standardmäßig nur das, was wir schon von IIS4 her kennen. Um das zu ändern, muß man die Eigenschaften der Website anzeigen, und dann in den Tab Custom Errors wechseln: Dort sucht man sich den 500.100 Fehler, und klickt auf Edit Properties. Ich habe hier die Datei my500-100handler.asp eingegeben, die ich im Laufe dieses Artikels noch vorstellen werde (auch 500-100.asp von der Default Web Site kann verwendet werden). Wichtig ist, daß man als Message Type URL auswählt. Wie kann man aber in einer ASP Datei auf den Fehler einer anderen zugreifen? Dies ermöglicht der Befehl Server.GetLastError, der ein ASPError Objekt zurückliefert (beide neu in IIS5), das den Fehler beschreibt:
Um die Verwendung der jeweiligen Eigenschaften zu verdeutlichen, habe ich mit my500-100handler.asp ein sehr einfach (designmäßig als auch vom Funktionsumfang) gehaltenes Fehlerbehandlungsscript geschrieben: <% ' den letzten Fehler abholen Set xObjLastError = Server.GetLastError() strASPErrorCode = xObjLastError.ASPCode nErrorNumber = xObjLastError.Number strErrorDescription = xObjLastError.Description strASPErrorDescription = xObjLastError.ASPDescription strErrorSource = xObjLastError.Source strCategory = xObjLastError.Category nLine = xObjLastError.Line nColumn = xObjLastError.Column strFilename = xObjLastError.File Response.Write strCategory & "'" & Hex(nErrorNumber) & "'<br>" Response.Write strErrorDescription & "<br>" If Len(strASPErrorCode) > 0 Then Response.Write "ASP Fehlercode: " & strASPErrorCode & "<br>" End If If Len(strASPErrorDescription) > 0 Then Response.Write "ASP Fehler, Beschreibung: " & _ strASPErrorDescription & "<br>" End If ' Wenn kein Fehler aufgetreten ist, dann liefert File ein Fragezeichen If strFilename <> "?" Then Response.Write strFilename If nLine > 0 Then Response.Write ", Zeile " & nLine End If If nColumn > 0 Then Response.Write ", Spalte " & nColumn End If If Len(strErrorSource) > 0 Then Response.Write "<br><pre>" & _ Server.HTMLEncode(strErrorSource) & "<br>" If nColumn > 0 Then Response.Write String((nColumn - 1), "-") & "^</pre><br>" End If End If End If %> Zuerst lese ich alle Eigenschaften aus, da ich sie mehrmals verwende. Danach gebe ich alle erhaltenen Informationen einfach an den Betrachter der Fehlerseite aus. Wichtig in diesem Zusammenhang ist, daß die Fehlerbehandlungsseite von ASP via Server.Transfer aufgerufen wird. Das bedeutet, als Programmierer habe ich Zugriff auf die unmodifizierten Request Collections, inklusive Form, QueryString und ServerVariables. Damit hat man einen guten Startpunkt, um einen guten Fehlerbericht aufzubereiten. SchlußbemerkungNeben der sicher dringenden Notwendigkeit dieses Skript designmäßig aufzumotzen kann man zusätzliche Funktionen einbauen, so zum Beispiel den ASP Fehler einem Administrator/Programmierer zu mailen, in einer Datenbank mitzuloggen und anderes mehr. Ebenfalls nicht aus dem Auge lassen sollte man die Möglichkeit, pro Web Applikation (eigentlich sogar bis auf einzelne Dateien hinab) eine eigene Fehlerseite definieren zu können - damit lassen sich für besonders kritische Skripts eigene Fehlerbehandlungsdateien generieren. Was passiert eigentlich, wenn in der zentralen Fehlerbehandlungsdatei ein ASP Fehler auftritt? Nichts - dieser Fehler wird dann normal angezeigt, die Fehlerseite wird nicht noch einemal aufgerufen. Download des CodesKlicken Sie hier, um den Download zu starten. Verwandte Artikel
Debuggen von ASP Skripts - Teil 1 Links zu anderen Sites
500-100.asp Returns "Type Mismatch" Error After Request.BinaryRead() Method Wenn Sie jetzt Fragen haben...Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten. Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.
Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.
©2000-2006 AspHeute.com |