2014-08-15 4 views
2

Мне потребовалось много времени, чтобы отследить проблему конфигурации Log4Net, когда строка подключения к базе данных была неправильной, потому что, когда XmlConfigurator.Configure() был вызван в коде, вместо того, чтобы бросать исключение, он просто зависает.Log4Net XmlConfigurator.Configure() зависает, когда строка подключения неверна. Ошибка в Log4Net?

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

Это действительно беспокоит меня, что он просто висел, а не бросает исключение из-за того, что логин не работает. Это какая-то ошибка в log4net?

+0

Если кто-то приходит вместе с хрустальным шаром, вы потребуется дополнительная информация. Конфигурационные файлы и код, который вы используете для совершения вызова, возможно, реализация сервиса и т. Д. – Tim

+0

@Tim False. См. Ответ ниже. :) – BVernon

ответ

2

Нет, это не ошибка, это documented behaviour:

log4net является наиболее усилий и система регистрации не в состоянии остановки.

Сбой при остановке означает, что log4net не будет выдавать неожиданные исключения во время выполнения, что может привести к сбою приложения. Если по какой-либо причине log4net выбрасывает неперехваченное исключение, отправьте электронное письмо в список рассылки [email protected] Необязанные исключения обрабатываются как серьезные ошибки, требующие немедленного внимания .

Если вы хотите, чтобы проверить, что конфигурация верна, the documentation suggests code like this:

Чтобы предотвратить молчаливый отказ log4net, log4net поддерживает способ оценки, если она была настроена, а также для оценки сообщений, созданных при запуске с 1.2.11. Чтобы проверить, была запущена log4net и настроено должным образом можно проверить свойство log4net.Repository.ILoggerRepository.Configured и перечислить конфигурации сообщений следующим образом:

if(!log4net.LogManager.GetRepository().Configured) 
{ 
    // log4net not configured 
    foreach(log4net.Util.LogLog message in 
      log4net.LogManager.GetRepository() 
        .ConfigurationMessages 
        .Cast<log4net.Util.LogLog()) 
    { 
     // evaluate configuration message 
    } 
} 
+1

Спасибо. +1 для объяснения, но есть кое-что, что я до сих пор не понимаю. Как заставить тупик «лучше», чем бросать неперехваченное исключение? По крайней мере, я мог бы игнорировать неперехваченное исключение в моем собственном приложении, и он не нарушил бы его. Но я ничего не могу сделать (разумно практично) в тупике. Мне кажется, что это на самом деле хуже, чем неперехваченное исключение, не так ли? – BVernon

+0

Я начал отмечать этот ответ, потому что он здесь единственный, но я просто не могу. Если «неперехваченные исключения обрабатываются как серьезные ошибки, требующие немедленного внимания», как вы говорите, то возникновение тупика следует рассматривать как более серьезную проблему в 10 раз. – BVernon

+0

В своем вопросе вы говорите, что проблема заключалась в том, что «строка подключения к базе данных неверна». Как это может вызвать тупик? – stuartd

Смежные вопросы