Unikaj printStackTrace (); użyj zamiast tego wywołania rejestratora

W mojej aplikacji uruchamiam swój kod przez PMD i wyświetla mi się następujący komunikat:

• Unikaj printStackTrace (); użyj zamiast tego wywołania rejestratora.

Co to znaczy?

Oznacza to, że powinieneś używać struktury logowania, takiej jak logback lub log4j i zamiast bezpośrednio drukować wyjątki:

e.printStackTrace();

powinieneś je logować za pomocą API tych frameworków:

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

Struktury rejestrowania zapewniają dużą elastyczność, np. Możesz wybrać, czy chcesz logować się do konsoli, czy do pliku - lub może pominąć niektóre komunikaty, jeśli uznasz, że nie są już potrzebne w jakimś środowisku.

Jeśli wywołasz printStackTrace()wyjątek, zostanie zapisany ślad System.erri trudno go skierować w inne miejsce (lub przefiltrować). Zamiast tego zaleca się użycie struktury rejestrowania (lub opakowania otaczającego wiele struktur rejestrowania, takich jak Apache Commons Logging) i rejestrowanie wyjątku przy użyciu tej struktury (np logger.error("some exception message", e).).

Dzięki temu możesz:

• zapisz instrukcję log w różnych miejscach naraz, np. w konsoli i pliku
• filtruj instrukcje dziennika według wagi (błąd, ostrzeżenie, informacje, debugowanie itp.) i pochodzenia (zwykle na podstawie pakietu lub klasy)
• mieć pewien wpływ na format dziennika bez konieczności zmiany kodu
• itp.

Program jakości produkcji powinien wykorzystywać jedną z wielu alternatyw rejestrowania (np. Log4j, logback, java.util.logging) do zgłaszania błędów i innych metod diagnostycznych. Ma to wiele zalet:

• Komunikaty dziennika trafiają do konfigurowalnej lokalizacji.
• Użytkownik końcowy nie widzi wiadomości, chyba że skonfigurujesz rejestrowanie w taki sposób, aby to robił.
• Możesz użyć różnych rejestratorów i poziomów rejestrowania itp., Aby kontrolować, ile rejestrowanych jest małych lub dużych ilości danych.
• Możesz użyć różnych formatów programu dołączającego, aby kontrolować wygląd rejestrowania.
• Dane wyjściowe logowania można łatwo podłączyć do większej platformy monitorowania / rejestrowania.
• Wszystkie powyższe czynności można wykonać bez zmiany kodu; tj. edytując plik konfiguracyjny rejestrowania wdrożonej aplikacji.

Z drugiej strony, jeśli używasz tylko printStackTrace, wdrażający / użytkownik końcowy ma niewielką kontrolę, jeśli w ogóle, a komunikaty logowania mogą zostać utracone lub wyświetlone użytkownikowi końcowemu w niewłaściwych okolicznościach. (I nic nie przeraża nieśmiałego użytkownika bardziej niż losowy ślad stosu).

W Simple e.printStackTrace () nie jest dobrą praktyką, ponieważ po prostu drukuje ślad stosu na standardowy błąd. Z tego powodu nie możesz tak naprawdę kontrolować, gdzie trafia to wyjście.

Prawie każda platforma rejestrowania zapewnia metodę, w której możemy przekazać obiekt do rzucania wraz z wiadomością. Lubić:

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

Drukują ślad stosu rzucanego przedmiotu.

Porozmawiajmy od koncepcji firmy. Log zapewnia elastyczne poziomy (zobacz Różnicę między logger.info i logger.debug ). Różni ludzie chcą widzieć różne poziomy, takie jak QA, programiści, ludzie biznesu. Ale e.printStackTrace () wypisze wszystko. Ponadto, na przykład, jeśli ta metoda będzie wywoływana spokojnie, ten sam błąd może zostać wyświetlony kilka razy. Wtedy pracownicy Devops lub Tech-Ops w Twojej firmie mogą być szaleni, ponieważ otrzymają te same przypomnienia o błędach. Myślę, że lepszym zamiennikiem mogłoby być log.error("errors happend in XXX", e) To również wydrukuje całą informację, która jest łatwa do odczytania niż e.printStackTrace ()

Głównym powodem jest to, że Proguard usuwał wywołania dziennika z produkcji. Ponieważ logując się lub drukując StackTrace, można je zobaczyć (informacje wewnątrz śladu stosu lub dziennika) w telefonie z Androidem, na przykład w aplikacji Logcat Reader. Więc jest to zła praktyka dla bezpieczeństwa. Ponadto nie mamy do nich dostępu podczas produkcji, lepiej byłoby usunąć je z produkcji. Ponieważ ProGuard usuwa wszystkie wywołania dziennika, a nie stackTrace, lepiej jest użyć bloków Log in catch i pozwolić im usunąć je z produkcji przez Proguard.