Избегайте printStackTrace(); вместо этого используйте логический вызов

Ответ 1

Это означает, что вы должны использовать фреймворк регистрации, например logback или log4j и вместо печати исключения напрямую:

e.printStackTrace();

вы должны занести их в журнал с помощью API этих фреймворков:

log.error("Ops!", e);

Структуры ведения журнала предоставляют вам большую гибкость, например. вы можете выбрать, хотите ли вы войти в консоль или файл, или, может быть, пропустить некоторые сообщения, если вы обнаружите, что они больше не актуальны в какой-либо среде.

Ответ 2

Если вы вызываете printStackTrace() для исключения, трассировка записывается в System.err, и его трудно перенаправить в другое место (или отфильтровать). Вместо этого вам рекомендуется использовать фреймворк протоколирования (или оболочку вокруг нескольких фреймворков протоколирования, например, Apache Commons Logging) и регистрировать исключение с использованием этой структуры (например, logger.error("some exception message", e)).

Выполнение этого позволяет:

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

Ответ 3

Программа качества продукции должна использовать одну из многих альтернатив ведения журнала (например, log4j, logback, java.util.logging), чтобы сообщать об ошибках и других диагностических показаниях. Это имеет ряд преимуществ:

• Сообщения журнала отправляются в настраиваемое местоположение.
• Конечный пользователь не видит сообщения, если вы не настроите журнал, чтобы он/она выполняли.
• Вы можете использовать разные регистраторы и уровни ведения журналов и т.д., чтобы контролировать, сколько записей записано немного или много.
• Вы можете использовать разные форматы appender, чтобы контролировать, как выглядит журнал.
• Вы можете легко подключить вывод журнала к более крупной системе мониторинга/ведения журнала.
• Все вышеизложенное может быть выполнено без изменения вашего кода; то есть путем редактирования конфигурационного файла журнала развертывания приложения.

В отличие от этого, если вы просто используете printStackTrace, у установщика/конечного пользователя мало какого-либо элемента управления, и сообщения о регистрации могут быть потеряны или показаны конечному пользователю в неприемлемых обстоятельствах. (И ничто не пугает робкого пользователя больше, чем случайная трассировка стека.)

Ответ 4

В Simple e.printStackTrace() не является хорошей практикой, потому что она просто выводит трассировку стека на стандартную ошибку. Из-за этого вы не можете контролировать, где этот выход идет.

Ответ 5

Почти каждая структура ведения журнала предоставляет метод, с помощью которого мы можем передать бросаемый объект вместе с сообщением. Подобно:

public trace(Marker marker, String msg, Throwable t);

Они печатают трассировку стека бросаемого объекта.

Ответ 6

Позвольте поговорить с концепцией компании. Журнал предоставляет вам гибкие уровни (см. Разница между logger.info и logger.debug). Разные люди хотят видеть разные уровни, такие как QA, разработчики, деловые люди. Но e.printStackTrace() распечатает все. Также, как если бы этот метод вызывался в спокойном состоянии, эта же ошибка может печататься несколько раз. Тогда сотрудники Devops или Tech-Ops в вашей компании могут сойти с ума, потому что они получат те же напоминания об ошибках. Я думаю, что лучшей заменой может быть log.error("errors happend in XXX", e) Это также выведет всю информацию, которая легче читается, чем e.printStackTrace()

Ответ 7

Основная причина в том, что Proguard удалит журналы вызовов из производства. Потому что, регистрируя или печатая StackTrace, можно увидеть их (информацию внутри трассировки стека или Log) внутри телефона Android, например, с помощью приложения Logcat Reader. Так что это плохая практика для безопасности. Также мы не получаем к ним доступ во время производства, лучше бы его сняли с производства. Поскольку ProGuard удаляет все вызовы Log, а не stackTrace, то лучше использовать Log in catch и блокировать их из Production by Proguard.