ASP.Net MVC-Ausnahmeprotokollierung kombiniert mit Fehlerbehandlung

Ich bin noch ein bisschen verwirrt mit all den verschiedenen Lösungen gibt, und wie die Attribute können sich gegenseitig stören, aber ich ging mit dieser Lösung:

public class LogErrorsAttribute: FilterAttribute, IExceptionFilter
{
    #region IExceptionFilter Members

    void IExceptionFilter.OnException(ExceptionContext filterContext)
    {
        if (filterContext != null && filterContext.Exception != null)
        {
            string controller = filterContext.RouteData.Values["controller"].ToString();
            string action = filterContext.RouteData.Values["action"].ToString();
            string loggerName = string.Format("{0}Controller.{1}", controller, action);

            log4net.LogManager.GetLogger(loggerName).Error(string.Empty, filterContext.Exception);
        }

    }

    #endregion
}

Benutze ich immer noch die [HandleError] - Attribut, wie in der ursprünglichen Frage, und ich nur schmücken Sie jeden controller mit einem [LogErrors] - Attribut.

Dies funktioniert für mich, als es hält die Fehlerprotokollierung in einem Ort und nicht zu duplizieren Ausnahmen protokolliert werden mehrere Male (was passiert, wenn ich verlängern [HandleError] und verwenden Sie das Attribut an mehreren stellen).

Ich glaube nicht, es wird möglich sein, beide miteinander zu kombinieren Ausnahme Logging und Fehlerbehandlung in einem atrribute oder Klasse, ohne es immer sehr langwierig und Komplex ist, oder die den Gebrauch von [HandleError]

Aber das funktioniert für mich, da ich dekorieren jeden controller nur einmal mit der [LogErrors] - Attribut, und schmücken Controller und Aktionen mit [HandleError] genau so, wie ich will, ohne dass Sie einander stören.

Update:

Hier ist ein Beispiel, Wie ich es verwenden:

[LogErrors(Order = 0)]
[HandleError(Order = 99)]
public class ContactController : Controller
{
    public ActionResult Index()
    {
        return View(Views.Index);
    }

    public ActionResult Directions()
    {
        return View(Views.Directions);
    }


    public ActionResult ContactForm()
    {
        FormContactMessage formContactMessage = new FormContactMessage();

        return View(Views.ContactForm,formContactMessage);
    }

    [HandleError(ExceptionType = typeof(SmtpException), View = "MessageFailed", Order = 1)]
    [AcceptVerbs(HttpVerbs.Post)]
    public ActionResult ContactForm(FormContactMessage formContactMessage)
    {
        if (ModelState.IsValid)
        {
            if (formContactMessage.IsValid)
            {
                SmtpClient client = new SmtpClient();

                MailAddress recipientAddress = new MailAddress(Properties.Settings.Default.ContactFormRecipientEmailAddress);
                MailAddress senderAddress = new MailAddress(Properties.Settings.Default.ContactFormSenderEmailAddress);
                MailMessage mailMessage = formContactMessage.ToMailMessage(recipientAddress, senderAddress);

                client.Send(mailMessage);

                return View("MessageSent");
            }
            else
            {
                ModelState.AddRuleViolations(formContactMessage.GetRuleViolations());
            }
        }
        return View(Views.ContactForm, formContactMessage);
    }

    private static class Views
    {
        public static string Index { get { return "Index"; } }
        public static string Directions { get { return "Directions"; } }
        public static string ContactForm { get { return "ContactForm"; } }

    }
}

In dem obigen code, SmtpExceptions in der ContactForm Aktion überlastung behandelt werden, auf eine sehr spezifische Art und Weise - dem Benutzer präsentiert sich mit einer ViewPage spezifisch für gesendete Nachrichten ist fehlgeschlagen, in diesem Fall heißt es "MessageFailed" . Alle anderen Ausnahmen behandelt werden, die durch das default-Verhalten von [HandleError]. Beachten Sie auch, dass die Protokollierung der Fehler tritt auf, gefolgt von Umgang mit Fehlern. Dies ist im folgenden angegeben:

[LogErrors(Order = 0)]
[HandleError(Order = 99)]

Update:

Gibt es eine alternative Lösung, mit einer sehr guten explanantion. Ich empfehle die Lektüre über es, um ein besseres Verständnis der Probleme beteiligt.

ASP.NET MVC HandleError-Attribut, Benutzerdefinierte Fehlerseiten und Protokollierung von Ausnahmen
(Dank an Scott Shepherd unten, die den link in einer Antwort weiter unten).

InformationsquelleAutor der Antwort Saajid Ismail