Bei einer Webanwendung sind Fehler unvermeidlich, daher sollten wir Vorkehrungen treffen und für eine angemessene Behandlung möglicher Fehler sorgen. Tatsächlich ist ein guter Fehlerbehandlungsmechanismus ein wichtiges Kriterium zur Messung der Qualität von Webanwendungen. Stellen Sie sich vor, wenn der Benutzer versehentlich die falsche URL in den Browser eingibt oder wenn der Benutzer einige Informationen bereitstellt, die zu Fehlern im Programm führen, lassen wir 404- oder 500-Fehlerseiten oder sogar Fehler zu wird den Benutzern präsentiert, was zweifellos einige Benutzer abschrecken wird. Wenn wir Webanwendungen entwickeln, sollten wir daher den Fehlerbehandlungsmechanismus vollständig verstehen.
Kehren wir zu ASP.NET zurück und stellen zwei Fragen, über die jeder nachdenken sollte: Wie viele Fehlerbehandlungsmechanismen stellt uns ASP.NET zur Verfügung? Wenn mehrere Fehlerbehandlungsmechanismen gleichzeitig verwendet werden, gibt es eine bestimmte Priorität zwischen ihnen? Mit dieser Frage im Hinterkopf werfen wir zunächst einen Blick auf unsere häufigste Web.Config-Datei:
Bezüglich des Einstellungselements
Schauen wir uns als Nächstes eine weitere Datei an, die ebenfalls sehr häufig verwendet wird: Global.asax. Woran denken Sie, wenn Sie dieses Dokument erwähnen? Ja, es handelt sich um Ereignisse, die sich auf die beiden wichtigsten Webanwendungsobjekte (Anwendung und Sitzung) beziehen. Unter diesen Ereignissen gibt es ein fehlerbezogenes Ereignis, das zur Anwendungskategorie „Fehler“ gehört, und die entsprechende Ereignisverarbeitungsmethode ist „Application_Error“. Wie der Name schon sagt, wird diese Ereignisbehandlungsmethode aufgerufen, wenn ein Fehler auf Anwendungsebene auftritt. Sie können dieser Methode also Code hinzufügen, um den Fehler zu behandeln, wie unten gezeigt:
protected void Application_Error(object sender, EventArgs e) {
Ausnahme objErr = Server.GetLastError().GetBaseException();
Response.Write("Fehler:" + objErr.Message);
Server.ClearError();
}
Hier sollte jeder auf die Verwendung von Server.ClearError() in der letzten Codezeile achten. Warum sollte diese Codezeile verwendet werden? Was passiert, wenn Sie es nicht verwenden? Hier werde ich es noch einmal versuchen. Nun, der zweite Fehlerbehandlungsmechanismus – die Verwendung der Ereignisbehandlungsmethode Application_Error in Global.asax – hat ebenfalls sein Debüt gegeben.
Man kann sagen, dass die beiden oben genannten Fehlerbehandlungsmethoden global sind. Die eine wird von der Anwendungskonfigurationsdatei abgeleitet und die andere ist die Ereignisbehandlungsmethode der Datei Global.asax, die im Stammverzeichnis der Anwendung abgelegt werden muss. Das Gegenteil des Globalen ist das Lokale, daher fragen wir uns natürlich: Gibt es einen Fehlerbehandlungsmechanismus, der für das Lokale gilt – eine bestimmte Seite? Die Antwort lautet „Ja“, und es gibt zwei Möglichkeiten: die Verwendung des ErrorPage-Attributs und die Verwendung der Page_Error-Ereignisbehandlungsmethode. Für den ersten Mechanismus können Sie die Eigenschaft „ErrorPage“ fast jederzeit festlegen, um zu bestimmen, zu welcher Seite umgeleitet wird, wenn auf der Seite ein Fehler auftritt. Für den zweiten Mechanismus ist er der Ereignisbehandlungsmethode „Application_Error“ sehr ähnlich, mit der Ausnahme, dass: Der Zeitpunkt der Auslösung ist unterschiedlich. Im Folgenden finden Sie zwei konkrete Beispiele:
protected void Page_Error(object sender, EventArgs e) {
Ausnahme objErr = Server.GetLastError().GetBaseException();
Response.Write("Fehler:" + objErr.Message);
Server.ClearError(); //Achten Sie auch auf die Verwendung dieses Codes
}
An diesem Punkt sind alle vier Fehlerbehandlungsmechanismen erschienen, und es ist an der Zeit, sie in eine Rangfolge zu bringen. Sortierung von hoher bis niedriger Priorität: Page_Error-Ereignisbehandlungsmethode > ErrorPage-Eigenschaft > Application_Error-Ereignisbehandlungsmethode > Konfigurationselement
Okay, das war's mit der Vorstellung der vier Fehlerbehandlungsmechanismen von ASP.NET, und es ist Zeit, über einige meiner eigenen Gefühle zu sprechen. Die Designer von ASP.NET haben in der Tat gründliche Überlegungen aus der Sicht der Entwickler angestellt und bieten uns daher bis zu vier Fehlerbehandlungsmechanismen zur Auswahl, was lobenswert ist. Aber um einen Werbeslogan zu paraphrasieren: Zu viel ist verwirrend, uns wird bei so vielen Fehlerbehandlungsmechanismen auch ein wenig schwindelig. Beim Vergleich der Fehlerbehandlung im J2EE-Bereich können wir feststellen, dass sie relativ einfach ist. Die erste ist die Einstellung, die