Уникайте 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, розгортач / кінцевий користувач має мало контролю, якщо взагалі не має, і повідомлення про реєстрацію можуть бути втрачені або показані кінцевому користувачеві за неналежних обставин. (І ніщо не лякає боязкого користувача більше, ніж випадковий слід стека.)

У простому застосуванні e.printStackTrace () не є доброю практикою, оскільки він просто роздруковує трасування стека до стандартної помилки. Через це ви не можете насправді контролювати, куди надходить цей результат.

Майже кожен фреймворк журналювання забезпечує метод, за допомогою якого ми можемо передавати об'єкт, що викидається, разом із повідомленням. Люблю:

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

Вони друкують стек об'єкта, що викидається.

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

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