Quel est le problème avec l'utilisation de System.err en Java?

Question

J'utilise l'analyseur de code statique Enerjy ( http://www.enerjy.com/ ). outil sur mon code Java. Il me dit que la ligne suivante:

System.err.println (" ignoré cette base de données ");

est mauvais car il utilise System.err. L'erreur exacte est la suivante: & Quot; JAVA0267 Utilisation de System.err & Quot;

.

Quel est le problème avec System.err?

Answer 1

Réponse courte: Il est considéré comme une mauvaise pratique de l'utiliser à des fins de journalisation.

Il convient de noter qu’à l’époque où il n’existait aucun framework de journalisation largement disponible / accepté, tout le monde utilisait System.err pour imprimer des messages d’erreur et empiler les traces sur la console. Cette approche peut convenir pendant la phase de développement et de test local, mais ne convient pas pour un environnement de production, car vous risquez de perdre des messages d'erreur importants. C'est pourquoi, dans la plupart des outils d'analyse statique, ce type de code est détecté et signalé comme une mauvaise pratique (ou un problème similaire).

Les infrastructures de journalisation fournissent à leur tour le moyen structuré et logique de consigner vos événements et vos messages d'erreur, car ils peuvent stocker le message dans divers emplacements persistants (fichier journal, fichier journal, etc.).

La résolution la plus évidente (et sans dépendances externes) de hack consiste à utiliser le framework de journalisation Java intégré via la classe java.util.logging.Logger, car il transfère les événements de journalisation à la console par défaut. Par exemple:

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

(ou vous pouvez simplement désactiver cette option d'analyse)

Answer 2

le descripteur de votre erreur est:

  

L'utilisation de System.err peut indiquer un code de débogage ou de passe-partout résiduel. Pensez à utiliser un   package de journalisation complet, comme Apache Commons, pour gérer la journalisation des erreurs.

Il semble que vous utilisiez System.err à des fins de journalisation, ce qui est sous-optimal pour plusieurs raisons:

• il est impossible d'activer la journalisation au moment de l'exécution sans modifier le binaire de l'application
• le comportement de journalisation ne peut pas être contrôlé en modifiant un fichier de configuration
• probablement beaucoup d'autres

Answer 3

Bien que je sois d’accord avec les points précédents concernant l’utilisation d’un cadre de journalisation, j’ai quand même tendance à utiliser System.err la sortie au même endroit: dans les crochets fermés. En effet, j’ai découvert que lors de l’utilisation des java.util.logging instructions de journal de structure ne sont pas toujours affichées si elles se produisent dans des crochets à fermeture. En effet, la bibliothèque de consignation contient probablement son propre point d'ancrage pour nettoyer les fichiers journaux et d'autres ressources, et comme vous ne pouvez pas vous fier à l'ordre dans lequel les points d'arrêt sont exécutés, vous ne pouvez pas vous fier aux <=> instructions fonctionnant comme prévu.

Consultez ce lien (la section & "Commentaires &") pour plus d'informations à ce sujet.

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

(Évidemment, l'autre alternative est d'utiliser un cadre de journalisation différent.)

Answer 4

System.err est vraiment plus destiné au débogage qu’autre chose. Il est préférable de gérer correctement les exceptions et de traiter les erreurs de manière plus conviviale. Si l'utilisateur est censé voir l'erreur, utilisez plutôt System.out.println.

Si vous souhaitez suivre ces erreurs du point de vue d'un développeur, vous devez utiliser un enregistreur.

Answer 5

Les objets écrits dans System.err sont généralement perdus au moment de l'exécution. Il est donc recommandé d'utiliser un cadre de journalisation plus flexible quant à l'emplacement de sortie du message, afin qu'il puisse être stocké et analysé. / p>

System.err et System.out pour les applications non console ne sont vus que par le développeur qui exécute le code dans son IDE, et des informations utiles peuvent être perdues si l'élément est déclenché en production.

Answer 6

System.err.println et System.out.println ne doivent pas être utilisés comme interface de consignation. STD-Output et STD-Error (ceux-ci sont écrits par System.out et .err) sont destinés aux messages des outils de ligne de commande.

Answer 7

System.err imprime sur la console. Cela peut convenir à un étudiant qui teste ses devoirs, mais ne conviendra pas à une application où ces messages ne seront pas vus (la console ne stocke que tant de lignes).

Une meilleure approche serait de lever une exception contenant le message qui serait normalement envoyé à la console. Une autre solution consiste à utiliser un logiciel de journalisation tiers qui stockerait ces messages dans un fichier pouvant être stocké à tout jamais.