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:
<?xml version="1.0"?>
<Konfiguration>
<system.web>
<customErrors mode="On" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" weitergeleitet="Error403.htm" />
<error statusCode="404" weitergeleitet="Error404.htm" />
</customErrors>
</system.web>
</configuration>
Bezüglich des Einstellungselements <customErrors> besteht meines Erachtens kein Grund, weitere Angaben zu machen. Weitere Informationen finden Sie im MSDN. Der erste Fehlerbehandlungsmechanismus – die Verwendung des Konfigurationselements <customErrors> von Web.Config – sollte der am häufigsten verwendete sein.
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:
<script language="C#" runat="server">
protected void Page_Load(object sender, EventArgs e) {
this.ErrorPage = "ErrorPage.htm";
}
</script>
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 <customErrors>. Obwohl die Rangfolge so ist, gibt es einen subtilen Zusammenhang zwischen den Ranglisten. Damit das Attribut „ErrorPage“ funktioniert, muss zunächst das Attribut „mode“ im Konfigurationselement „<customErrors>“ auf „Ein“ gesetzt sein Wenn dies der Fall ist, wird weiterhin eine Fehlerbehandlung mit niedrigerer Priorität ausgelöst. Dies gilt auch für die Ereignisbehandlungsmethode Application_Error. Die Reihenfolge ist festgelegt, aber die Reihenfolge ist nicht das wichtigste Thema. Man kann sogar sagen, dass sie keine große Bedeutung hat, da diese vier Verarbeitungsmechanismen in vielen Fällen möglicherweise nicht gemischt werden. Ich denke, die wichtigste Frage ist die Auswahl dieser Fehlerbehandlungsmechanismen. Zu diesem Thema hoffe ich, dass erfahrene Freunde ihre Meinung teilen können.
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 <customErrors> entspricht. Wir können auch ähnliche Konfigurationselemente aus der am häufigsten verwendeten web.xml-Datei in J2EE-Projekten finden: <errorPage>; zweitens ist Seite keine wichtige Entität event Das Treibermodell ist nicht erforderlich, daher kann ich den entsprechenden Verarbeitungsmechanismus für die Methoden Application_Error und Page_Error nicht finden. Im J2EE-Bereich wird schließlich mehr Wert auf Request und Response gelegt, sobald ein Fehler in der logischen Verarbeitung auftritt , Wir können die Anfrage einfach über RequestDispatcher an das entsprechende Fehlerbehandlungsmodul verteilen. Dies ist tatsächlich eine sehr flexible Verarbeitungsmethode. Freunde, die interessiert sind, möchten möglicherweise mehr darüber erfahren.