printStackTrace и Logger Frameworks в Java

В Java обработка исключений может выполняться несколькими способами. Давайте различать обработку исключений с помощью среды ведения журналов как log4j или sl4j, где оба они могут либо перенаправлять журналы в файл, либо обрабатывать исключение.

Если вместо среды Logger мы используем метод класса исключений printStackTrace() для обработки исключения и получения стека вызовов исключения, перенаправляя его в файл, а не в стандартный вывод/консоль ошибок, теперь возникают следующие вопросы:

  1. Будет ли более поздняя реализация обрабатывать исключение вообще ИЛИ просто распечатает исключение в файл?
  2. На каком основании реализация Logger лучше, чем printStacktrace() в производственной среде?

Заранее спасибо!


person Akhil Gupta    schedule 23.11.2016    source источник
comment
Я обычно вижу, что оба используются на самом деле. Я видел, как использовались log4j и sl4j, и при обнаружении исключения выходные данные printStacktrace() отправляются в регистратор.   -  person Tim Biegeleisen    schedule 23.11.2016
comment
Спасибо, Тим, но мне было интересно, какой вариант выбрать в производстве, поскольку у нас могут быть добавления и вращение, доступные для достижения с помощью конфигурации, - это единственное, что делает его более выгодным по сравнению с printstacktrace()   -  person Akhil Gupta    schedule 23.11.2016
comment
Что вы имеете в виду под более поздней реализацией в первом вопросе?   -  person Niklas P    schedule 23.11.2016
comment
Это все равно, что сравнивать сохранение вещей в файл с использованием базы данных. Если вы делаете только очень простые вещи, вы можете не увидеть разницы. То же самое относится и здесь.   -  person Kayaman    schedule 23.11.2016
comment
@Niklas позже я намеревался сказать, используем ли мы printStackTrace() против использования структуры регистратора   -  person Akhil Gupta    schedule 23.11.2016
comment
Вы знаете, что у Java есть своя структура ведения журнала, верно? А в Java 9 будет еще более простая структура ведения журналов, доступная через метод System.getLogger.   -  person VGR    schedule 23.11.2016
comment
Возможный дубликат Avoid printStackTrace(); вместо этого используйте вызов регистратора   -  person MT0    schedule 13.06.2017


Ответы (2)


К 2) Фреймворки ведения журнала не являются лучшим обработчиком файлов, но, например, извлекают конфигурацию выхода из кода. Поэтому, когда вы меняете конфигурацию (например, другой уровень детализации журналов для разработки и производства), вам не нужно менять код — вы просто используете другие конфигурации фреймворка для каждого этапа тестирования. Если вы хотите изменить имена файлов журнала, размер файла журнала (ротацию) или конкретную информацию журнала для разных пакетов или классов, вы можете легко сделать это, изменив конфигурацию.

person Niklas P    schedule 23.11.2016
comment
Спасибо, Никлас. Думаю, регистратор можно сравнить с printStackTrace() с точки зрения печати сообщений журнала, но не с точки зрения обработки исключений, поскольку ни один из них не обрабатывает исключения, а просто ведет журналы в разные файлы/потоки... Я прав? - person Akhil Gupta; 23.11.2016
comment
Я не уверен, что вы имеете в виду под обработкой исключений. Я лично использую термин обработка исключений, когда реализую бизнес-логику, что делать, когда возникает исключение — прервать бизнес-логику/транзакцию и отобразить конкретную ошибку, прервать бизнес-логику/транзакцию и отобразить стандартную ошибку и записать подробности, завершить бизнес-логика/транзакция и в фоновом режиме регистрируются детали, ... - все эти решения НЕ могут быть выполнены с помощью структуры ведения журнала. Таким образом, я бы сказал, что структура ведения журнала НЕ может выполнять обработку исключений. - person Niklas P; 24.11.2016

Существует множество причин, по которым вам не следует использовать printStackTrace() и, , если это не так. новинка здесь, давайте не будем заново изобретать колесо (особое внимание ссылка God's Perfect Exception, действительно очень хорошая).

Фреймворки ведения журналов позволяют нам многое (так много):

  • Отправляйте наши журналы в разные места одновременно. Большинство из них поставляются с несколькими приложениями, которые выполняют такие действия, как вывод в консоль и файл, а также отправку сообщений журнала с использованием электронной почты или JMS, например;
  • Настройте сообщения с уровнями серьезности, источником, набором ключей фильтрации и т. д.;
  • Простая и настраиваемая конфигурация на основе файлов xml/properties без необходимости изменения кода Java;
  • Хорошая асинхронная обработка, в основном для распределенных систем;
  • Конфигурация детализации, настройка способа регистрации ваших исключений;
  • и Т. Д.

Особенно хороша функция пользовательского добавления, потому что мы можем отправлять журналы не в файлы, например Splunk, Логика сумо, Loggly, logstash и т. д., как это уже делают многие компании в настоящее время. анализировать и контролировать свои производственные системы.

Кроме того, рассмотрите возможность проанализировать правильную структуру ведения журналов для ваших нужд.

person bosco    schedule 23.11.2016