Какой уровень использовать для регистрации трассировки стека исключений в Java? - PullRequest
Новая
       42

Какой уровень использовать для регистрации трассировки стека исключений в Java?

0 голосов
/ 07 октября 2011

Я ищу документ с рекомендациями (или ваше мнение) о том, как эффективно регистрировать исключения и их трассировку стека. Конечно, при условии, что один из популярных каркасов журналирования, таких как Log4J, SLF4J, java.util.logging и т. Д.

Меня особенно интересует ваше мнение о том, на каком уровне должны регистрироваться трассировки стека.

Я слышал мало противоречащих друг другу мнений, таких как:

  • трассировки стека должны регистрироваться только на уровне DEBUG, в то время как уровень ERROR должен содержать только «читабельное» сообщение об ошибке
  • трассировки стека должны регистрироваться на уровне ОШИБКИ, чтобы предоставить оператору максимальное количество информации, необходимой для поиска основной причины исключения

Я нашел пару интересных статей, однако ни одна из них не касается этой конкретной темы:

, что, вероятно, означает, что у авторов этих статей были те же проблемы, что и у меня: -)

Мне бы очень хотелось узнать ваше мнение по этому вопросу.

Ответы [ 3 ]

8 голосов
/ 07 октября 2011

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

Также обратите внимание, что: 

log.error("Houston, we have a problem", ex);

напечатает удобочитаемое сообщение в строке, помеченной как ОШИБКА, в то время как трассировка стека следует за этой строкой.Если вы хотите, чтобы ваши ошибки были понятны только человеку, просто сделайте grep ERROR.

1 голос
/ 07 октября 2011

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

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

Поэтому я бы посоветовал сделать следующее:

  1. Создайте собственную структуру исключений
  2. Включите в сообщение конкретные коды ошибок, для справки
  3. Записать сообщение об ошибке на ОШИБКУ
  4. Записать трассировку стека на DEBUG
  5. НИКОГДА не показывать пользователю ни то, ни другое. Вместо этого покажите полезное сообщение. Может быть, включить способ сообщить об ошибке (с помощью трассировки стека) с минимальным запуском.

Примечание. Если вы пишете внутреннее «корпоративное» программное обеспечение, забудьте обо всем, что я написал. : -)

0 голосов
/ 07 октября 2011

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

...