Domanda

Sto usando l'analizzatore di codice statico Enerjy ( http://www.enerjy.com/ ) strumento sul mio codice Java. Mi dice che la seguente riga:

System.err.println (" Ignorato quel database ");

è errato perché utilizza System.err. L'errore esatto è: & Quot; JAVA0267 Uso di System.err & Quot;

Cosa c'è di sbagliato nell'usare System.err?

È stato utile?

Soluzione

Risposta breve: è considerato una cattiva pratica usarlo per scopi di registrazione.

È un'osservazione che ai vecchi tempi in cui non esistevano framework di registrazione ampiamente disponibili / accettati, tutti usavano System.err per stampare messaggi di errore e impilare tracce sulla console. Questo approccio potrebbe essere appropriato durante la fase di sviluppo e test locali, ma non è appropriato per un ambiente di produzione, poiché potresti perdere importanti messaggi di errore. Per questo motivo, in quasi tutti gli strumenti di analisi statica oggi questo tipo di codice viene rilevato e contrassegnato come cattiva pratica (o un problema con un nome simile).

I framework di registrazione a loro volta forniscono il modo strutturato e logico per registrare eventi e messaggi di errore in quanto possono archiviare il messaggio in varie posizioni persistenti (file di registro, db di registro, ecc.)

La risoluzione hack più ovvia (e priva di dipendenze esterne) è quella di utilizzare il framework di registrazione Java incorporato attraverso la classe java.util.logging.Logger in quanto inoltra gli eventi di registrazione alla console per impostazione predefinita. Ad esempio:

final Logger log = Logger.getLogger(getClass().getName());
...
log.log(Level.ERROR, "Something went wrong", theException);

(o potresti semplicemente disattivare quell'opzione di analisi)

Altri suggerimenti

il descrittore del tuo errore è:

  

L'uso di System.err può indicare il debug residuo o il codice del boilerplate. Prendi in considerazione l'utilizzo di a   pacchetto di registrazione completo come Apache Commons per gestire la registrazione degli errori.

Sembra che tu stia utilizzando System.err per scopi di registrazione, che non è ottimale per diversi motivi:

  • è impossibile abilitare la registrazione in fase di esecuzione senza modificare il file binario dell'applicazione
  • il comportamento della registrazione non può essere controllato modificando un file di configurazione
  • probabilmente molti altri

Sebbene io sia d'accordo con i punti precedenti sull'utilizzo di un framework di registrazione, tendo ancora a usare System.err l'output in un unico posto: all'interno dei ganci di arresto. Questo perché ho scoperto che quando si utilizzano le istruzioni di registro java.util.logging non vengono sempre visualizzate se si verificano in hook di arresto. Questo perché presumibilmente la libreria di registrazione contiene il proprio hook di arresto per ripulire i file di registro e altre risorse e poiché non è possibile fare affidamento sull'ordine in cui vengono eseguiti gli hook di arresto, non è possibile fare affidamento su <=> istruzioni che funzionano come previsto.

Dai un'occhiata a questo link (la " Commenti " sezione) per maggiori informazioni su questo.

http://weblogs.java.net/blog/ dwalend / archive / 2004/05 / shutdown_hooks_2.html

(Ovviamente l'altra alternativa è utilizzare un diverso framework di registrazione.)

System.err è davvero più per scopi di debug che altro. Si preferisce una corretta gestione delle eccezioni e la gestione degli errori in un modo più intuitivo. Se l'utente deve visualizzare l'errore, utilizza invece System.out.println.

Se vuoi tenere traccia di quegli errori dal punto di vista di uno sviluppatore, dovresti usare un logger.

Le cose scritte su System.err vengono generalmente perse in fase di runtime, quindi è consigliabile utilizzare un framework di registrazione più flessibile su dove inviare il messaggio, in modo che possa essere archiviato come file e analizzato.

System.err e System.out per le applicazioni non console sono sempre e solo visualizzati dallo sviluppatore che esegue il codice nel proprio IDE e informazioni utili potrebbero andare perse se l'elemento viene attivato nella produzione.

System.err.println e System.out.println non devono essere usati come interfaccia di loggging. STD-Output e STD-Error (sono scritti da System.out e .err) sono per i messaggi dagli strumenti della riga di comando.

System.err stampa sulla console. Questo può essere adatto a uno studente che verifica i compiti, ma non è adatto per un'applicazione in cui questi messaggi non verranno visualizzati (la console memorizza solo così tante righe).

Un approccio migliore sarebbe quello di lanciare un'eccezione che contenga il messaggio che verrebbe normalmente inviato alla console. Un'alternativa a questo sarebbe utilizzare software di registrazione di terze parti che memorizzerebbe questi messaggi in un file che può essere archiviato per sempre.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top