Я читал этот статья и, похоже, было три разных события исключения.
Я хотел бы использовать структуру ведения журнала, такую как Serilog, для захвата исключений.
Должен ли я помещать код регистрации в ExceptionFilter, затем в ExceptionLogger, затем в ExceptionHandler? Я предполагаю, что все они имеют доступ к полному стеку исключений.
Кроме того, должен ли я также помещать код регистрации в Application_Error в global.asax?





Если вы хотите зарегистрировать исключения, вы должны поместить код в свой ExceptionHandler или Application_Error (это то же самое). ExceptionFilter классифицирует ошибки. Application_Error обрабатывает ошибку, если приложение генерирует исключения.
ExceptionFilter разделяет и классифицирует ошибки с помощью вашей логики ошибок, ExceptionLogger регистрирует, когда ошибка (ы) произошли так же, с помощью вашей логики регистрации ошибок.
Короче вы можете поместить свой код в Application_Error в global.asax
По-видимому, вам необходимо регистрировать все необработанные исключения для мониторинга общего состояния вашего приложения. Для этого используется ExceptionHandler будет вашим лучшим вариантом.
Если выброшено необработанное исключение, оно будет получено следующим в том же порядке:
Чтобы лучше понять разницу между ними, я объясню назначение каждого из них.
Решение для просмотра всех необработанных исключений, перехваченных веб-API. Существует вероятность возникновения исключения еще до того, как вы нажмете действие контроллера или после того, как контроллер уже вернул ответ о результате действия (помните, что возвращаемое значение действия не передается напрямую в браузер, а обрабатывается запросом/ответом). трубопровод).
Например, исключение может возникнуть в конструкторе контроллера, во время маршрутизации, сериализации ответа и т. д.
Можно зарегистрировать несколько регистраторов исключений, и все они будут вызываться в случае исключения.
Имейте в виду, что регистраторы исключений вызываются перед фильтрами исключений, где они будут обрабатываться, поэтому при их регистрации вы можете получить много ненужной информации.
Цель: видеть все необработанные исключения (еще до того, как они попадут в фильтры исключений)
Сфера: глобальный
Используйте его для обработки ожидаемых исключений (например, UnauthorizedException, созданного вашей бизнес-логикой) и настраивайте ответ в зависимости от типа исключения. Другими словами, используйте его для обработки исключения (например, если исключение UnathorizedException, перенаправьте пользователя на страницу входа).
Первый фильтр для обработки исключения «выигрывает», так что другие обработчики исключений даже не будут вызываться, если исключение уже было обработано (установлен объект ответа)
Это можно и нужно использовать для регистрации необработанных исключений. В одном приложении может быть зарегистрирован только один. Его также можно использовать для отображения пользователю общей страницы ошибки — «Произошла неизвестная ошибка».
Рекомендую взглянуть на этот статья
Я думаю, что мы должны использовать структуру журнала в регистраторах исключений, потому что из документа docs.microsoft.com/en-us/aspnet/web-api/overview/error-handling/… — регистраторы исключений — это решение для просмотра всех необработанных исключений, перехватываемых веб-API. - Обработчики исключений — это решение для настройки всех возможных ответов на необработанные исключения, перехваченные веб-API. - Фильтры исключений — это самое простое решение для обработки подмножества необработанных исключений, связанных с конкретным действием или контроллером.
К вашему сведению, когда соединение будет прервано и новое ответное сообщение не может быть отправлено, будут вызваны регистраторы, но обработчик не будет вызван.
Это зависит от того, что вы хотите зарегистрировать. Вы можете поместить их во все обработчики или ни в один из них.