Когда регистрировать исключение?

Question

try 
{ 
    // Code 
} 
catch (Exception ex) 
{ 
    Logger.Log("Message", ex); 
    throw; 
} 

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

Answer 1

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

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

Answer 2

Вы должны зарегистрировать его так же, как бросить его так, чтобы приложение имело это доступное для него для входа в систему. В частности, если это библиотека, вы должны ее зарегистрировать, так как вы не должны не должны предположить, что приложение обязательно зарегистрирует его (это может быть или не быть).

Answer 3

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

Причина, по которой я предпочитаю регистрироваться на более высоких уровнях, заключается в том, что более высокие уровни содержат больше информации о контексте и могут знать более подходящие способы сообщать/регистрировать эти ошибки. Так как в любом случае исключения содержат в них всю информацию о трассировке стека, я не думаю, что вы многого выиграете, зарегистрировавшись сразу же после возникновения исключения. Вы должны быть осторожны в отношении исключений, которые преобразуются в другие виды исключений, однако, поэтому постоянно используйте InnerException, если вы конвертируете исключения по мере их обработки, чтобы хранить всю информацию об источнике ошибки.

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

Answer 4

Ошибки журнала также могут быть методом отладки приложения.

Answer 5

Использование log4net. Шутки в сторону.

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

В log4net, например, я могу сделать

ILog log = LogManager.GetLogger("some logger"); 
log.Debug("some debugging info"); 
log.Info("some message meaningful in the domain"); 
log.Warn("something might be occurring that merits your attention"); 
log.Error("Everything just went to hell") 

Администратор приложение может установить различные уровни входа, что он заинтересован в том, чтобы. Можно даже позволить ему изменить эту конфигурацию во время выполнения.По сути, с надежной библиотекой протоколирования, такой как log4net, вы можете направлять различные уровни ведения журнала из разных источников в разные приложения. Например, вы можете иметь скользящий файл со всеми сообщениями о регистрации на прошлой неделе, хранящимися на жестком диске, сообщениями об информации, предупреждениях и ошибках, которые не возникают на вашем уровне доступа к данным, вставляемом в базу данных, и все отправленные ошибки вам по электронной почте.

Я думаю, что то, что вы описываете, довольно отчетливо находится под уровнем «отладочного» журнала.

Вы можете, конечно же, реализовать уровни ведения журнала самостоятельно, но если кто-либо из вашей библиотеки заинтересован в получении всей информации об отладке, им придется изучать вашу систему, в дополнение к тому, что они используют. Лучше стандартизировать.

Так передовой опыт:

1. использовать уровни разных протоколирований.
2. Не сворачивайте свои собственные рамки ведения журнала, используйте log4net (который действительно в этот день и возраст довольно стандартный) или, по крайней мере, Microsoft entlib logging block.