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

В моем приложении я запускаю свой код через PMD, и он показывает мне это сообщение:

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

Что это значит?

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

e.printStackTrace();

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

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

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

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

Это позволит вам:

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

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

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

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

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

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

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

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

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

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