EnterpriseLibrary ExceptionHandling не записывает в мой файл журнала

Question

В моем веб-приложении разрешено ведение журнала предприятия и исключения. Файл web.config настроен так, что все должно работать. Ранее он работал на других серверах, поскольку в файле trace.log, который находится в корне приложения, содержится информация трассировки. Я очистил свой файл trace.log на локальном компьютере, чтобы проверить, работает ли он, когда появляются исключения. Я создал тестовую страницу, которая выдает исключение. Затем я вызываю ExceptionPolicy.HandleException (например, «Политика исключений») и перебрасываю при необходимости. Мой trace.log остается пустым, поэтому я не могу понять, почему он не работает. Я довольно новичок в этом, но я знаю, что это должно было сработать раньше. В чем я не уверен, так или иначе, будет ли исключение записано в файл журнала или только в результате вызова HandleException ()?

Я пытаюсь отладить, почему это не работает.

Answer 1

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

В основном наш стек состоит из

слой DA Слой BO Слой приложения

Уровень BO обращается к DA. Если что-то идет не так, то это обрабатывается в Try / Catch. Внутри функции catch он вызывает ExceptionPolicy.HandleException () и возвращает логическое значение rethrow. Однако он не проверяет это значение для выполнения другого выброса, что означает, что ошибка не передается во время выполнения ошибки ASP.NET.

Странно, они устанавливают флаг IsExceptionGenerated для объекта BO, который затем проверяется на уровне приложения. Слой приложения затем перенаправляется в «~ \ error.aspx».

Я изменил это, поэтому политика проверена и исключение переброшено. Но нигде не было зарегистрировано исключение. Я не хочу, чтобы множество журналов разбрасывалось по всему приложению непосредственно перед перенаправлением на error.aspx. Поэтому я добавил обработчик ошибок global.asax для регистрации ошибки. Я также могу разорвать все перенаправления и позволить web.config указать прямой путь к странице ошибки, используя раздел CustomErrors.

Кажется, теперь работает!

Хотелось бы узнать, является ли response.redirects ("error.aspx") плохой практикой во всем приложении. Я хотел бы знать, о чем они думали, когда писали это. Я понимаю, что иногда вы можете захотеть совершить ошибку, а иногда продолжить изящно, но все же отследить ее, но, безусловно, это можно сделать с помощью различных политик исключений.

Есть идеи у кого-нибудь?