Ich bin kürzlich einem asp.net mvc-Projekt beigetreten, bei dem es nicht viel Konsistenz im Umgang mit Ausnahmen im Controller gibt; Einige Entwickler geben Daten an den Client zurück, um den Benutzer wissen zu lassen, was falsch ist, andere werfen sie zurück, damit sie den Server-Level-Handler erreichen, der sie verarbeitet und protokolliert - ohne den Benutzer wissen zu lassen, was los ist.
Es scheint mir offensichtlich, dass beide Ansätze alleine falsch sind und sich stattdessen ergänzen müssen; Woran ich festhalte, ist, wie man das macht. Ich gehe davon aus, dass der Eventual Exception Handler / Logger den Benutzer auf eine Fehler-Webseite umleiten könnte, wenn er etwas besonders Scheußliches auffängt, aber das beschränkt den Mechanismus auf nur schweres Zeug.
Ich bin auf der Suche nach einer Möglichkeit, sowohl "throw" als auch "return ..." zu einer Zeit zu tun, wenn ich eine Ausnahme abfange, also sortiere ich und protokolliere Server-Seite und bekomme Daten-Client-Seite, die lässt Ich erzähle dem Benutzer, dass es einen Schluckauf gab.
Meine Expertise mit asp.net ist sehr begrenzt, und während ich glaube, dass ich mvc genug verstehe, damit es kein Problem ist, ist dies eine Art "Was ist die beste Praxis?" Frage von jemandem, der mit Leuten arbeitet, die sich nicht mit Best Practices beschäftigen.
Es gibt ein gutes Projekt namens Elmah zum Protokollieren von Fehlern und Ausnahmen in ASP.NET-Anwendungen. Sie finden es hier
ELMAH (Fehlerprotokollierung von Modulen und Handlern) ist ein anwendungsweites Problem Fehlerprotokollierungseinrichtung, die vollständig steckbar ist. Es kann sein dynamisch zu einer laufenden ASP.NET-Webanwendung hinzugefügt oder sogar alle ASP.NET Web-Anwendungen auf einer Maschine, ohne Notwendigkeit Neukompilierung oder Neu-Bereitstellung.
Einmal wurde ELMAH in eine laufende Web-Anwendung fallengelassen Bei entsprechender Konfiguration erhalten Sie folgende Funktionen ohne Ändern einer einzelnen Zeile Ihres Codes:
- Protokollierung fast aller nicht behandelten Ausnahmen.
- Eine Web-Seite zu remote Zeigen Sie das gesamte Protokoll der umcodierten Ausnahmen an.
- Eine Webseite zur Remote-Ansicht die vollständigen Details einer protokollierten Ausnahme, einschließlich des farbigen Stapels Spuren.
- In vielen Fällen können Sie den ursprünglichen gelben Bildschirm von überprüfen Tod, den ASP.NET für eine bestimmte Ausnahme selbst mit generiert hat Der customErrors-Modus ist deaktiviert.
- Eine E-Mail-Benachrichtigung über jeden Fehler bei die Zeit es auftritt.
- Ein RSS-Feed der letzten 15 Fehler aus dem Protokoll.
Die MVC-Anwendung, an der ich arbeite, implementiert Application_Error in Global.asax , um von der Anwendung geworfene Ausnahmen zu behandeln, und leitet den Benutzer dann auf eine Standardfehlerseite um. Der Controller für die Fehlerseite behandelt die Protokollierung und zeigt gerade genug Informationen über den Fehler an, damit ein Support-Mitarbeiter seine Sitzung im System finden und Probleme beheben kann.
Tags und Links c# exception-handling asp.net