поймать все необработанные исключения в ASP.NET Web Api

Как мне перехватить все необработанные исключения, возникающие в ASP.NET Web Api, чтобы я мог их регистрировать?

Пока я пробовал:

• Создать и зарегистрировать ExceptionHandlingAttribute
• Реализуйте Application_Errorметод вGlobal.asax.cs
• Подписываться на AppDomain.CurrentDomain.UnhandledException
• Подписываться на TaskScheduler.UnobservedTaskException

Он ExceptionHandlingAttributeуспешно обрабатывает исключения, которые возникают в методах действий контроллера и фильтрах действий, но другие исключения не обрабатываются, например:

• Исключения, возникающие, когда IQueryableметод, возвращаемый методом действия, не может выполнить
• Исключения, создаваемые обработчиком сообщений (т.е. HttpConfiguration.MessageHandlers)
• Исключения, возникающие при создании экземпляра контроллера

По сути, если исключение приведет к возврату клиенту 500 Internal Server Error, я хочу, чтобы это было зарегистрировано. Реализация Application_Errorхорошо справилась с этой задачей в веб-формах и MVC - что я могу использовать в веб-API?

Теперь это возможно с WebAPI 2.1 (см. Что нового ):

Создайте одну или несколько реализаций IExceptionLogger. Например:

public class TraceExceptionLogger : ExceptionLogger
{
    public override void Log(ExceptionLoggerContext context)
    {
        Trace.TraceError(context.ExceptionContext.Exception.ToString());
    }
}

Затем зарегистрируйтесь с помощью HttpConfiguration вашего приложения внутри обратного вызова конфигурации, например:

config.Services.Add(typeof(IExceptionLogger), new TraceExceptionLogger());

или напрямую:

GlobalConfiguration.Configuration.Services.Add(typeof(IExceptionLogger), new TraceExceptionLogger());

Ответ Yuval предназначен для настройки ответов на необработанные исключения, обнаруженные веб-API, а не для ведения журнала, как указано на связанной странице . См. Подробности в разделе «Когда использовать» на странице. Регистратор вызывается всегда, но обработчик вызывается только тогда, когда может быть отправлен ответ. Короче говоря, используйте средство ведения журнала для ведения журнала и обработчик для настройки ответа.

Кстати, я использую сборку v5.2.3, а в ExceptionHandlerклассе нет HandleCoreметода. Я думаю, что эквивалент Handle. Однако просто подклассы ExceptionHandler(как в ответе Ювала) не работают. В моем случае я должен реализовать IExceptionHandlerследующее.

internal class OopsExceptionHandler : IExceptionHandler
{
    private readonly IExceptionHandler _innerHandler;

    public OopsExceptionHandler (IExceptionHandler innerHandler)
    {
        if (innerHandler == null)
            throw new ArgumentNullException(nameof(innerHandler));

        _innerHandler = innerHandler;
    }

    public IExceptionHandler InnerHandler
    {
        get { return _innerHandler; }
    }

    public Task HandleAsync(ExceptionHandlerContext context, CancellationToken cancellationToken)
    {
        Handle(context);

        return Task.FromResult<object>(null);
    }

    public void Handle(ExceptionHandlerContext context)
    {
        // Create your own custom result here...
        // In dev, you might want to null out the result
        // to display the YSOD.
        // context.Result = null;
        context.Result = new InternalServerErrorResult(context.Request);
    }
}

Обратите внимание, что, в отличие от регистратора, вы регистрируете свой обработчик, заменяя обработчик по умолчанию, а не добавляя.

config.Services.Replace(typeof(IExceptionHandler),
    new OopsExceptionHandler(config.Services.GetExceptionHandler()));

Чтобы ответить на мой собственный вопрос, это невозможно!

Обработка всех исключений, вызывающих внутренние ошибки сервера, кажется базовой возможностью, которую должен иметь веб-API, поэтому я отправил в Microsoft запрос на глобальный обработчик ошибок для веб-API :

https://aspnetwebstack.codeplex.com/workitem/1001

Если вы согласны, перейдите по этой ссылке и проголосуйте за нее!

А пока в отличной статье « Обработка исключений веб-API ASP.NET» показано несколько различных способов отлова нескольких различных категорий ошибок. Это сложнее, чем должно быть, и он не улавливает все внутренние ошибки сервера, но это лучший подход, доступный сегодня.

Обновление: глобальная обработка ошибок теперь реализована и доступна в ночных сборках! Он будет выпущен в ASP.NET MVC v5.1. Вот как это будет работать: https://aspnetwebstack.codeplex.com/wikipage?title=Global%20Error%20Handling

Вы также можете создать глобальный обработчик исключений, реализовав IExceptionHandlerинтерфейс (или унаследовав ExceptionHandlerбазовый класс). Он будет последним в цепочке выполнения после всех зарегистрированных IExceptionLogger:

IExceptionHandler обрабатывает все необработанные исключения из всех контроллеров. Это последний в списке. Если возникает исключение, сначала вызывается IExceptionLogger, затем ExceptionFilters контроллера и, если все еще не обработано, реализация IExceptionHandler.

public class OopsExceptionHandler : ExceptionHandler
{
    public override void HandleCore(ExceptionHandlerContext context)
    {
        context.Result = new TextPlainErrorResult
        {
            Request = context.ExceptionContext.Request,
            Content = "Oops! Sorry! Something went wrong."        
        };
    }

    private class TextPlainErrorResult : IHttpActionResult
    {
        public HttpRequestMessage Request { get; set; }

        public string Content { get; set; }

        public Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)
        {
            HttpResponseMessage response = 
                             new HttpResponseMessage(HttpStatusCode.InternalServerError);
            response.Content = new StringContent(Content);
            response.RequestMessage = Request;
            return Task.FromResult(response);
        }
    }
}

Подробнее об этом здесь .

У вас могут быть существующие блоки try-catch, о которых вы не знаете.

Я думал, что мой новый global.asax.Application_Errorметод не вызывается постоянно для необработанных исключений в нашем устаревшем коде.

Затем я нашел несколько блоков try-catch в середине стека вызовов, которые вызывали Response.Write в тексте исключения. Вот и все. Вывалил текст на экран, а затем убил исключение как камень.

Итак, исключения обрабатывались, но ничего полезного не делалось. Как только я удалил эти блоки try-catch, исключения, как и ожидалось, распространялись на метод Application_Error.