it-swarm-eu.dev

Was sind die endgültigen Richtlinien für die benutzerdefinierte Fehlerbehandlung in ASP.NET MVC 3?

Der Prozess der benutzerdefinierten Fehlerbehandlung in ASP.NET MVC (in diesem Fall 3) scheint unglaublich vernachlässigt zu werden. Ich habe die verschiedenen Fragen und Antworten hier im Internet gelesen, Hilfeseiten für verschiedene Tools (wie Elmah), aber ich habe das Gefühl, dass ich mich in einem vollständigen Kreis befunden habe und immer noch nicht die beste Lösung habe. Mit Ihrer Hilfe können wir vielleicht einen neuen Standardansatz für die Fehlerbehandlung festlegen. Ich möchte die Dinge einfach halten und dies nicht überentwickeln.

Hier sind meine Ziele:

Für Serverfehler/Ausnahmen :

  1. Debugging-Informationen in dev anzeigen
  2. Anzeigen einer freundlichen Fehlerseite in der Produktion
  3. Protokollieren Sie Fehler und senden Sie sie per E-Mail an den Administrator in der Produktion
  4. 500 HTTP-Statuscode zurückgeben

Für 404 nicht gefundene Fehler :

  1. Anzeigen einer freundlichen Fehlerseite
  2. Protokollieren Sie Fehler und senden Sie sie per E-Mail an den Administrator in der Produktion
  3. 404 HTTP-Statuscode zurückgeben

Gibt es eine Möglichkeit, diese Ziele mit ASP.NET MVC zu erreichen?

44
RyanW

Ich werde die Art und Weise teilen, wie ich dies getan habe, das war Teil der ursprünglichen Frage.

Erstens die Probleme, auf die ich gestoßen bin:

  1. Wenn customErrors aktiviert ist (d. H. In der Produktion), verschluckt das globale Attribut HandleError Ausnahmen und rendert Ihre Fehleransicht. Sie können sie jedoch nicht mit einem Addon-Tool wie elmah protokollieren, da elmah sie nie sieht. Sie könnten es in Ihrer Ansicht protokollieren, aber es ist eine Ansicht, die falsch zu sein scheint. Das globale HandleError-Attribut wird in der MVC 3 RTM Visual Studio-Projektvorlage) neu angezeigt.

  2. customErrors mit URLs für MVC-Endpunkte gibt 302 Statuscodes zurück. Es gibt die Eigenschaft redirectmode, aber Sie können mvc-URLs in customErrors nicht abgleichen und den ResponseRewrite-Modus verwenden. ( https://stackoverflow.com/questions/781861/customerrors-does-not-work-when-setting-redirectmode-responserewrite/3770265#3770265 )

  3. Das vollständige Vermeiden von customErrors und das Behandeln aller benutzerdefinierten Elemente in Ihrer App führt zu einer hohen Komplexität, IMO. (Ich habe das geliebt: https://stackoverflow.com/questions/619895/how-can-i-properly-handle-404s-in-asp-net-mvc/2577095#2577095 , aber es war nicht nicht richtig für unser Projekt)

Meine Lösung

Ich habe MVC komplett aus der Gleichung genommen. Ich habe den globalen Filter HandleErrorAttribute in global.asax entfernt und mich ganz auf die Konfiguration von customErrors konzentriert. Ich habe ihn auf die Verwendung von WebForm-Umleitungen verschoben und in den Umleitungsmodus auf ResponseRewrite geändert, um die 302 HTTP-Antwortcodes zu vermeiden .

<customErrors mode="On" defaultRedirect="/Error.aspx" redirectMode="ResponseRewrite">
  <error statusCode="404" redirect="/NotFound.aspx" />
</customErrors>

Dann in NotFound.aspx page_load event, setze das Response.StatusCode auf 404 und in Error.aspx den Code 500 setzen.

Ergebnisse:

Die Ziele für beide wurden mit den Elmah-Protokollen, der benutzerfreundlichen Fehlerseite und dem Statuscode mit einer Codezeile auf den Code-Behinds erreicht. Wir machen es nicht wie die frühere Lösung auf "MVC-Weise", aber ich bin damit einverstanden, wenn es sich um zwei Codezeilen handelt.

23
RyanW

Ich denke, dass MVC, ASP und Ihr bevorzugtes Framework für die Protokollierung/Ausnahmebehandlung Ihre Ziele recht gut handhaben können. ELMAH und Enterprise Library bieten beide eine benutzerfreundliche Ausnahmebehandlung und Protokollierung. Wählen Sie also Ihren Favoriten aus. I. Ich werde hier nicht auf die Vor- und Nachteile eines jeden eingehen.

HINWEIS: Sie können keine benutzerfreundliche Fehlerseite anzeigen UND ein HTTP 404 oder 500 zurückgeben, wie in Ihrer Frage vorgeschlagen. Wenn Sie eine freundliche Fehlerseite zurückgeben, lautet der an Ihren Browser zurückgegebene HTTP-Code 302. Dies ist eine Weiterleitung zur freundlichen Fehlerseite.

Freundliche Fehlerseiten

Es hört sich so an, als könnten Sie Ihre Ziele mit den altmodischen Einstellungen von web.config erreichen, die seit einiger Zeit Teil von ASP.net sind. Sie erwähnen, dass Debug-Informationen in der Entwicklung und freundliche Seiten in der Produktion angezeigt werden. Sie können hierfür den Abschnitt mit benutzerdefinierten Fehlern der web.config verwenden (Setzen Sie CustomErrors = "Off", um Debug-Informationen anzuzeigen). Ich gehe davon aus, dass Sie mit dem CustomErrors-Attribut vertraut sind, wenn Sie dies nicht lesen:

http://msdn.Microsoft.com/en-us/library/h0hfz6fc.aspx

Wenn Sie eine genauere Kontrolle darüber benötigen, welche Fehleransichten angezeigt werden, verwenden Sie das HandleError-Attribut von MVC. Auf diese Weise können Sie für jede Aktion/Steuerung unterschiedliche Fehleransichten auswählen.

http://weblogs.asp.net/scottgu/archive/2008/07/14/asp-net-mvc-preview-4-release-part-1.aspx

Ausnahmeprotokollierung

Es hört sich so an, als ob Sie auf alle Ihre Ausnahmen auf die gleiche Weise reagieren möchten ('Fehler protokollieren und per E-Mail an den Administrator in der Produktion senden'). In diesem Fall können Sie am einfachsten Code hinzufügen

Application_Error (Objektabsender, EventArgs e)

in Ihrem global.asax. Hier können Sie an das von Ihnen ausgewählte Protokollierungsframework übergeben.

Wenn Sie mehr Kontrolle über Ihre Ausnahmeprotokollierung/-behandlung wünschen, können Sie HandleErrorAttribute in Unterklassen unterteilen und überschreiben

OnException(System.Web.Mvc.ExceptionContext filterContext)

dies ist ein weiterer Ort, an dem Sie an das von Ihnen ausgewählte Protokollierungsframework weitergeben können.

https://stackoverflow.com/questions/183316/asp-net-mvc-handleerror

Dies gibt Ihnen mehr Kontrolle als die oben erwähnte Application_Error-Technik.

Im Allgemeinen bietet MVC eine umfassende Kontrolle über den Umgang mit Fehlern. Wenn Sie dieses Steuerelement nicht benötigen, können Sie auf die ASP.net-Methoden zurückgreifen, um beispielsweise Fehlerseiten in Ihrer web.config zu definieren.

5
nixon