Стратегия обработки исключений и ведения журнала в .NET.

Я создаю многоуровневое приложение, имеющее веб-приложение ASP.NET MVC. Он основан на обычаях, таких как уровень презентации, бизнес-уровень, уровень данных и т.д. Как создать/использовать достойный механизм обработки исключений? Я читал "Шаблоны и практики", что вам нужно выкидывать исключения из разных слоев.

Также регистрируется. Где происходит каротаж? В веб-приложении MVC?

Как вы перенаправляете на разные страницы ошибок в зависимости от типа ошибки?

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

Ответ 1

Во-первых, я бы предложил прочитать статью Vexing Exceptions " Эрик Липперт. Это должно дать вам некоторые разумные рекомендации по обработке исключений (и больше об исключении).

Когда дело доходит до регистрации исключений, самым простым и чистым подходом является наличие обработчика исключений верхнего уровня, ответственного за обработку всех необработанных исключений и запись их в журнал для анализа. Это можно сделать в приложениях ASP.NET с помощью события HttpApplication.Error, которое можно подключить через файл Global.asax.

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

Ответ 2

В моем приложении MVC3 я использую ELMAH для обработки исключений, как описано здесь Как заставить ELMAH работать с атрибутом ASP.NET MVC [HandleError]?, а если Мне нужно зарегистрировать собственное сообщение. Я использую методы Trace, которые поступают из System.Diagnostics, здесь полезная ссылка Переопределение System.Diagnostics.Trace.WriteLine для входа в файл.

UPDATE Теперь вы можете настроить elmah в своем приложении непосредственно с пакетом NuGet. http://gregorsuttie.wordpress.com/2011/02/02/elmah-using-nuget-what-they-are-and-why-you-should-use-them-part-1/

Ответ 3

Взгляните на корпоративную библиотеку. Он предоставит вам очень гибкий инструмент каротажа и другие товары, которые, я думаю, вам понравится. Например: вы можете использовать блок приложений для инъекций полиции (taht реализует AOP), чтобы уловить все исключения в вашем коде, не набирая строку кода.

Ответ 4

Я бы использовал Log4Net, завернутый в пользовательский бизнес-класс logger, поэтому везде, в коде, никто не знает, что мы используем Log4net, и в случае необходимости было бы легко изменить структуру ведения журнала в будущем. Для обработки исключений, как обычно, если вы не справляетесь с этим, бросьте его в любом случае на имя метода, фактические значения параметров и т.д. Было много дискуссий здесь, в SO о том, когда ловить, когда скрывать и когда бросать исключения...

Конечно, в главном потоке (пользовательском интерфейсе) должен быть обработчик события необработанного исключения, который будет регистрировать все правильно, а не просто сбой приложения.

Ответ 5

В большинстве инфраструктур ведения журнала .NET есть встроенные функции поддержки ASP.NET(или должны); для Serilog это пакет Serilog.Extras.Web на NuGet. Там не так много, чтобы настроить, установка пакета в ваше приложение Serilog приведет к регистрации ошибок ASP.NET & c.

(Я работаю над Serilog и просто написал сообщение примерно в этом сценарии.)