Evita printStackTrace (); utilizzare invece una chiamata logger


Risposte:


139

Significa che dovresti usare un framework di registrazione come o e invece di stampare direttamente le eccezioni:

e.printStackTrace();

dovresti registrarli usando l'API di questo framework:

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

I framework di registrazione ti danno molta flessibilità, ad esempio puoi scegliere se vuoi accedere alla console o al file - o forse saltare alcuni messaggi se li trovi non più rilevanti in qualche ambiente.


39

Se chiami printStackTrace()un'eccezione, la traccia viene scritta System.erred è difficile instradarla altrove (o filtrarla). Invece di farlo, ti consigliamo di utilizzare un framework di registrazione (o un wrapper attorno a più framework di registrazione, come Apache Commons Logging) e registrare l'eccezione usando quel framework (ad esempio logger.error("some exception message", e)).

Ciò ti consente di:

  • scrivere l'istruzione log in posizioni diverse contemporaneamente, ad esempio la console e un file
  • filtra le istruzioni di log per gravità (errore, avviso, informazioni, debug ecc.) e origine (normalmente basato su pacchetto o classe)
  • hanno una certa influenza sul formato del registro senza dover modificare il codice
  • eccetera.

17

Un programma di qualità della produzione dovrebbe utilizzare una delle tante alternative di registrazione (ad es. Log4j, logback, java.util.logging) per segnalare errori e altre funzioni di diagnostica. Questo ha una serie di vantaggi:

  • I messaggi di registro vanno in una posizione configurabile.
  • L'utente finale non vede i messaggi a meno che non configuri la registrazione in modo che lo faccia.
  • È possibile utilizzare diversi logger e livelli di registrazione, ecc. Per controllare la quantità minima o maggiore di registrazione registrata.
  • È possibile utilizzare diversi formati di appender per controllare l'aspetto della registrazione.
  • È possibile collegare facilmente l'output di registrazione a un framework di monitoraggio / registrazione più ampio.
  • Tutto quanto sopra può essere fatto senza modificare il codice; cioè modificando il file di configurazione della registrazione dell'applicazione distribuita.

Al contrario, se si utilizza solo printStackTrace, il deployer / utente finale ha poco o nessun controllo e i messaggi di registrazione possono essere persi o mostrati all'utente finale in circostanze inappropriate. (E niente terrorizza un utente timido più di una traccia di stack casuale.)


6

In Simple, e.printStackTrace () non è una buona pratica, perché stampa semplicemente la traccia dello stack sull'errore standard. Per questo motivo non puoi davvero controllare dove va questo output.


0

Quasi ogni framework di registrazione fornisce un metodo in cui possiamo passare l'oggetto lanciabile insieme a un messaggio. Piace:

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

Stampano lo stacktrace dell'oggetto lanciabile.


Questo non risponde alla domanda.
Stephen C

-1

Parliamo dal concetto di azienda. Log offre livelli flessibili (vedere Differenza tra logger.info e logger.debug ). Persone diverse vogliono vedere livelli diversi, come QA, sviluppatori, uomini d'affari. Ma e.printStackTrace () stamperà tutto. Inoltre, come se questo metodo fosse chiamato riposante, lo stesso errore potrebbe essere stampato più volte. Quindi le persone Devops o Tech-Ops nella tua azienda potrebbero essere pazze perché riceveranno gli stessi promemoria di errore. Penso che un sostituto migliore potrebbe essere log.error("errors happend in XXX", e) Questo stamperà anche intere informazioni che sono di facile lettura rispetto a e.printStackTrace ()


-3

Il motivo principale è che Proguard rimuoverebbe le chiamate di registro dalla produzione. Perché registrando o stampando StackTrace, è possibile vederli (informazioni all'interno dello stack trace o Log) all'interno del telefono Android, ad esempio dall'applicazione Logcat Reader. Quindi è una cattiva pratica per la sicurezza. Inoltre, non vi accediamo durante la produzione, sarebbe meglio essere rimossi dalla produzione. Poiché ProGuard rimuove tutte le chiamate di registro non stackTrace, è meglio utilizzare i blocchi catch di accesso e lasciarli rimossi dalla produzione di Proguard.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.