Ошибка приложения не срабатывает, когда customerrors = " On"

Я решил эту проблему, создав ExceptionFilter и регистрируя ошибку там вместо Application_Error. Все, что вам нужно сделать, это добавить вызов в In в RegisterGlobalFilters

log4netExceptionFilter.cs

using System
using System.Web.Mvc;

public class log4netExceptionFilter : IExceptionFilter
{
    public void OnException(ExceptionContext context)
    {
        Exception ex = context.Exception;
        if (!(ex is HttpException)) //ignore "file not found"
        {
            //Log error here
        }
    }
}

глобальные.асакс.cs

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
    filters.Add(new log4netExceptionFilter()); //must be before HandleErrorAttribute
    filters.Add(new HandleErrorAttribute());
}

я нашел статьи который описывает гораздо более чистый способ создания пользовательских страниц ошибок в веб-приложении MVC3, который не препятствует возможности регистрировать исключения.

решение заключается в использовании <httpErrors> элемент .

Я настроил мой Web.конфигурации вот так...

<httpErrors errorMode="DetailedLocalOnly" existingResponse="Replace">
  <remove statusCode="404" subStatusCode="-1" />
  <remove statusCode="500" subStatusCode="-1" />
  <error statusCode="404" path="/Error/NotFound" responseMode="ExecuteURL" />
  <error statusCode="500" path="/Error" responseMode="ExecuteURL" />
</httpErrors>

я тоже настроен customErrors иметь mode="Off" (как предлагается в статье).

что делает ответы, переопределенные действиями ErrorController. Вот этот контроллер:

public class ErrorController : Controller
{
    public ActionResult Index()
    {
        return View();
    }

    public ActionResult NotFound()
    {
        return View();
    }
}

представления очень прямолинейны, я просто использовал стандартный синтаксис Razor для создания страниц.

этого должно быть достаточно для использования пользовательских страниц ошибок с MVC.

Я также нуждался в регистрации исключений, поэтому я украл Марка использования пользовательского фильтра исключений...

public class ExceptionPublisherExceptionFilter : IExceptionFilter
{
    public void OnException(ExceptionContext exceptionContext)
    {
        var exception = exceptionContext.Exception;
        var request = exceptionContext.HttpContext.Request;
        // log stuff
    }
}

последнее, что вам нужно так это зарегистрируйте фильтр исключений в своем глобальные.асакс.cs file:

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
    filters.Add(new ExceptionPublisherExceptionFilter());
    filters.Add(new HandleErrorAttribute());
}

это похоже на гораздо более чистое решение, чем мой предыдущий ответ, и работает так же хорошо, насколько я могу судить. Мне это нравится, особенно потому, что я не чувствовал, что борюсь против структуры MVC; это решение фактически использует его!

в случае ASP.NET MVC5 использовать

public class ExceptionPublisherExceptionFilter : IExceptionFilter
    {
        private static Logger _logger = LogManager.GetCurrentClassLogger();
        public void OnException(ExceptionContext exceptionContext)
        {
            var exception = exceptionContext.Exception;
            var request = exceptionContext.HttpContext.Request;
            // HttpException httpException = exception as HttpException;
            // Log this exception with your logger
            _logger.Error(exception.Message);
        }
    }

вы можете найти его в FilterConfig.cs of .

Мне нравится ответ Марка с ExceptionFilter, но другой вариант, если у вас есть все ваши контроллеры, производные от одного и того же базового контроллера, - это просто переопределить OnException в вашем базовом контроллере. Вы можете сделать свой журнал и по электронной почте там. Это имеет то преимущество, что вы можете использовать любые зависимости, которые вы уже ввели в свой базовый контроллер с вашим контейнером IoC.

вы все еще можете использовать свой IoC с IExceptionFilter, но это немного сложнее настройка Привязок.

насколько я знаю, вы передаете управление на страницу, указанную в параметре url, и ваше уведомление о событии будет сидеть здесь, а не Application_Error

<customErrors defaultRedirect="myErrorPage.aspx"
              mode="On">
</customErrors>

много информации можно найти здесь:http://support.microsoft.com/kb/306355

чтобы обойти это, я в конечном итоге оставил customerrors отключенным и обрабатывал все ошибки из события Application_Error в global.асакс. Это немного сложно с MVC, поскольку я не хотел возвращать перенаправление 301, я хотел вернуть подходящие коды ошибок. Более подробную информацию можно посмотреть в моем блоге по адресу http://www.wduffy.co.uk/blog/using-application_error-in-asp-net-mvcs-global-asax-to-handle-errors/ но окончательный код приведен ниже...

void Application_Error(object sender, EventArgs e)
{
    var error = Server.GetLastError();
    var code = (error is HttpException) ? (error as HttpException).GetHttpCode() : 500;

    if (code != 404)
    {
            // Generate email with error details and send to administrator
    }

    Response.Clear();
    Server.ClearError();

    string path = Request.Path;
    Context.RewritePath(string.Format("~/Errors/Http{0}", code), false);
    IHttpHandler httpHandler = new MvcHttpHandler();
    httpHandler.ProcessRequest(Context);
    Context.RewritePath(path, false);
}

а вот это контроллер

public class ErrorsController : Controller
{

    [HttpGet]
    public ActionResult Http404(string source)
    {
            Response.StatusCode = 404;
            return View();
    }

    [HttpGet]
    public ActionResult Http500(string source)
    {
            Response.StatusCode = 500;
            return View();
    }

}

эта запись в блоге помогла мне:

http://asp-net.vexedlogic.com/2011/04/23/asp-net-maximum-request-length-exceeded/

если вы используете IIS 7.0 или выше, вы можете изменить свой веб.конфигурационный файл для обработки слишком больших запросов. Есть некоторые предостережения, но вот пример:

<system.webServer>
  <security>
    <requestFiltering>
      <requestLimits maxAllowedContentLength="1048576" />
    </requestFiltering>
  </security>
  <httpErrors errorMode="Custom" existingResponse="Replace">
    <remove statusCode="404" subStatusCode="13" />
    <error statusCode="404" subStatusCode="13" prefixLanguageFilePath="" path="/UploadTooLarge.htm" responseMode="Redirect" />
  </httpErrors>
</system.webServer>

есть дополнительные сведения об этих элементах файла конфигурации здесь:

http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering/requestLimits

код состояния 404.13 определяется как"слишком большая длина содержимого". Одна важная вещь, чтобы отметить, что maxAllowedContentLength задается в байтах. Это отличается от maxRequestLength настройки вы найдете в разделе <system.web> раздел, который указан в килобайтах.

<system.web>
  <httpRuntime maxRequestLength="10240" />
</system.web>

также обратите внимание, что path атрибут должен быть абсолютным путем, когда responseMode и Redirect, поэтому добавьте имя виртуального каталога, если это необходимо. Информативные ответы Джесси Уэбба показывают, как это сделать с responseMode="ExecuteURL", и я думаю, что этот подход тоже будет работать хорошо.

этот подход не работает, если вы разрабатываете с помощью сервера разработки Visual Studio (Cassini, веб-сервер, интегрированный в Visual Studio). Я предполагаю, что это будет работать в IIS Express, но я не проверял это.

у меня была та же проблема, где Application_Error() не получил удар. Я перепробовал все, пока, наконец, не шагнул через то, что происходило. У меня был какой-то пользовательский код в событии ELMAH, который добавлял JSON к электронной почте, которую он отправляет, и там была нулевая ошибка!

исправление внутренней ошибки позволило коду перейти к Application_Error() событие, как ожидалось.