Eine Webanwendung hat viele Qualitäten, aber es gibt eine dunkle Seite, die wir kennen müssen, und sie hat viele Fehler. Obwohl wir alle Vorsichtsmaßnahmen treffen und alle Komponententests durchführen können, wird es immer Fälle und Situationen geben, die wir nicht gesehen haben. die in einer Produktionsumgebung ausgenutzt werden können.
Wenn ein schwerwiegender Fehler ausgelöst wird und der Benutzer als letztes die Fehlermeldung von ASP.NET MVC sehen soll, müssen wir lernen, mit Fehlern und Ausnahmen umzugehen, damit wir die Richtlinien für unsere Vorgehensweise festlegen können muss das problem lösen.
Behandlung eines Fehlers in ASP.NET MVC
Wenn wir mit HTTP- Anfragen und Benutzereingaben arbeiten, kann etwas schief gehen, und es ist unsere Aufgabe, dies zu minimieren, obwohl wir nicht alle Fälle kennen werden, wenn wir eine Komponente erstellen können, die auf eine bestimmte Weise mit den Fehlern umgeht, die wir nicht kennen.
Mit dem Framework können wir personalisierte Fehlerseiten erstellen, wenn wir die entsprechende Option aktivieren. Wenn also ein Fehler oder eine Ausnahme auftritt, die wir nicht verwalten, können wir eine Seite anzeigen, die weniger schwerwiegend ist als die klassische ASP.NET MVC , die wir in der folgenden Abbildung sehen können:
Obwohl wir die Meldung verwerfen können, gibt es etwas Besorgniserregendes. Wenn der Quellcode anzeigt, wo der Fehler aufgetreten ist, kann dies zu Sicherheitslücken führen. Daher ist es wichtig, dass diese Seite in der Produktion nie angezeigt wird.
Benutzerdefinierte Fehlerseite
Fehlerfreiheit ist zwar der Idealzustand, aber an sich schon eine Utopie. Daher müssen wir uns mit dem Problem auseinandersetzen, und sie treten immer auf. In ASP.NET MVC haben wir drei Möglichkeiten, mit diesen Problemen umzugehen.
Die erste besteht darin, die Standardseite anzuzeigen, die wir im vorherigen Bild gesehen haben. Wenn also ein Fehler auftritt, wird er mit allen damit verbundenen Risiken angezeigt. Der zweite Status ist nur die Anzeige unserer benutzerdefinierten Fehlerseite. Dies hilft uns, den Quellcode unserer Anwendung nicht sichtbar zu machen.
Und schließlich der dritte und einer der nützlichsten Zustände, dass nur die personalisierte Fehlerseite angezeigt wird, wenn auf die Anwendung von einer Remoteadresse aus zugegriffen wird. Dieser letzte Modus hilft uns beim Debuggen, da wir die Anwendung ausführen und darin navigieren localhost zeigt die Standardseite der Fehler an und hilft somit bei allen Details. Wenn es sich jedoch um einen Client handelt, der von einem anderen Computer aus verbunden ist, wird nur der benutzerdefinierte Fehler angezeigt.
In der folgenden Abbildung sehen wir ein Beispiel für das Anpassen dieser Direktive der Konfigurationsdatei:
Wir sehen, dass wir bestimmte Seiten auf bekannte Fehler wie Nicht gefunden oder 404 einstellen können, wir können es auch mit Fehler 500 und anderen Codes tun. Damit beenden wir dieses Tutorial, mit dem wir ein wenig die grundlegende Art des Umgangs mit Fehlern in ASP gelernt haben .NET MVC .