Discussion :

[boijea]

Hi all,

Je ne suis pas encore un expert en Eclipse et je n'arrive pas à trouver "le truc" comment identifier un null qui vient sur la console ... tout seul!

Mon application GUI, basé sur Hibernate, est tout simplement énorme, plus de 100 classes et 4 packages. Pour obtenir ce null, j'ai deux cas et je peux les reproduire en cliquant sur le menu correspondant: reproductible à chaque coup.

La démarche normale est de poser un breakpoint au bon endroit, de faire du pas à pas, et de reposer le breakpoint toujours plus précisément. Mais cela ne donne rien: j'ai trop de threads et cela vient d'autre part.

La seconde démarche est de faire un Search File sur tous les fichiers de mes 4 packages ... mais il y en a ... beaucoup!

Mes "traces" en debug mode (log4j) ne sortent rien.

Normalement, si on écrit un System.out.println(...) ou un System.err.println(...), on écrit quelque chose comme: System.out.println("Je suis ici ..." + quelqueChose): alors le Search/File est facile.
Mais dans mon cas, j'ai vraisemblablement un tout simple et stupide System.out.println(objet) ou mon objet est juste null. J'en ai trouvé quelques uns, mais ils ne sont pas actif dans ce cas!

Je me suis demandé alors s'il existait des outils pour déposer automatiquement des breakpoints sur un ensemble d'instructions particulières ... mais faut pas révé, je crois. C'est là que je me suis dit que ce forum pourrait m'aider!

Pour terminer, mon:
null
vient tout seul, sans rien devant et vraisemblablement avec un \n puisque dans le second cas de mon application (autre menu) le second null vient dessous.

Pour le "fun" j'ai même essayé ces deux instructions:

System.out.close();
System.err.close();

Ils ferment bien les deux canaux de sortie (et les null ne viennent plus) mais ne me donnent pas d'exception et mon application tourne normalement comme d'aiileurs lorsque les null viennent. J'aimerais simplement les nettoyer ... et comprendre.

Merci d'avance pour quelques idées!

[Seb666]

J'ai pas tout compris à ton message mais avec Eclipse tu peux t'arrêter automatiquement sur une exception en l'ajoutant dans les breakpoint.

Dans l'onglet BREAKPOINTS de la vue DEBUG, il y a un bouton J! (Add Java Exception Breakpoint)
Tu mets par exemple çà: *Exception*
et tu lances ton appli en mode Debug et tu reproduis ton problème.
Cela devrait s'arrêter au bon endroit

[Laurent.B]

Mon application GUI, basé sur Hibernate, est tout simplement énorme, plus de 100 classes et 4 packages.

Oulahlah oui, 100 classes pour une application qui doit être embryonnaire, qu'est-ce que c'est énorme ! Non, je me moque un peu parce que pour toi c'est beaucoup mais pour d'autres c'est pas grand chose. Bon bref, c'est pas le pb

Mes "traces" en debug mode (log4j) ne sortent rien.

Normalement, si on écrit un System.out.println(...) ou un System.err.println(...), on écrit quelque chose comme: System.out.println("Je suis ici ..." + quelqueChose): alors le Search/File est facile.
Mais dans mon cas, j'ai vraisemblablement un tout simple et stupide System.out.println(objet) ou mon objet est juste null. J'en ai trouvé quelques uns, mais ils ne sont pas actif dans ce cas!

Si tu utilises log4j, oublie tout ce qui est System.out et System.err !!
Ton application devrait en être complètement dépourvue, justement parce que ça va à l'encontre du bénéfice de log4j et que du coup tu as moins le contrôle sur les logs.

Donc ensuite, tout se joue dans le fichier de config de log4j. C'est à toi de donner le niveau de log par défaut. Si tu as 'INFO', c'est sûr que tu ne verras pas ce qui doit sortir au niveau DEBUG, à part pour les packages pour lesquels tu auras paramétré un niveau plus bas. En revanche, si tu mets ton niveau de log par défaut sur 'DEBUG', le risque est de ralentir pas mal l'application et d'afficher largement trop de logs....
D'autre part, il faut que ton pattern de log soit paramétré correctement afin de faire ressortir les infos qui t'intéressent, comme, le nom de la classe, son package, la méthode concernée, la ligne...etc.

Donc en résumé, tant que tu n'auras pas un fichier de config log4j potable, tu n'auras pas d'information correcte sur la provenance de ce null qui s'affiche et qui en plus n'est sans doute même pas issu d'une exception apparemment (tu aurais une stack trace). Ou alors, c'est que tu as mis ton system.out dans un catch d'une exception, ce qui doit être remplacé par au minimum ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
catch(UneException e)
{
    log.error("Erreur : ", e);
}

Pour la config log4j, le mieux est d'aller sur le site d'origine, ou de chercher des ressources ici, tu devrais en trouver également.

[boijea]

Hello,

Bon c'est vendredi, il a fait froid cette semaine, et on est un peu fatigué.

Merci quand même, pour vos réponses, mais pour ce qui est de mon null, c'est toujours null, et il est toujours là. Pour le debug, ou le log4j, je pense que je connais déjà bien ces sujets. Le null ne vient pas d'exceptions.

J'ai bien aimé l'embryonnaire! Je fais du Java depuis que Java était en Alpha et C++ un peu plus qu'en beta! Bref, il n'y a pas 100 classes, mais 536, donc on dira en gestation. Si je tapais à deux doigts tout le code Java écrit par plusieurs softi, disons 2 caractères par seconde en incluant de temps en temps une réflexion et une pause café, cela donnerait pas mal d'heures pour ces 2.896.548 caractères!

Merci encore ... mais je trouverai la faute ... et je donnerai le pourquoi!