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

Question

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

Использовать 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 (что на самом деле является в наши дни и в наши дни довольно стандартным) или, по крайней мере, блок ведения журнала entlib от Microsoft .

Answer 4

Журнал исключений также может быть методом отладки приложения.

Answer 5

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