J'ai le code suivant:
Exception in thread "main" java.lang.NullPointerException
at org.Test.myMethod(Test.java:674)
at org.TestRunner.anotherMethod(TestRunner.java:505)
at java.util.ArrayList(ArrayList.java:405)
8 Réponses :
Peut-être que vous n'avez pas d'appendeur pour la sortie de la console. Vous envisagez d'ajouter un. Sinon, connectez-le comme LOGGER.Error (ex); avec log4j ou slf4j
Pendant un certain temps, je pensais que cela pourrait être dû à la console de la journalisation. J'ai donc essayé de stocker l'exception dans une chaîne et de le remédier à moi. L'e-mail que contenait uniquement "java.lang.nullpointereException"
Si vous lancez à plusieurs reprises une exception, l'arrêt JVM remplit dans la trace de la pile. Je ne sais pas pourquoi, mais il peut être de réduire la charge sur la JVM. Vous devez regarder une trace de pile antérieure pour voir les détails.
No more stack trace after 20707 thrown.
L'exception pourrait être attrapée et jetée quelque part avant votre bloc de prise. Peut-être dans une autre classe que vous appelez à faire la logique.
Un Exception créé comme
Nouvelle exception (nouveau lancable ("Java.lang.nullpointereException")));
va imprimer quelque chose comme ce que tu vois .
Il s'est avéré que dans le bloc d'essai, il a apporté un appel à une autre méthode qui a eu un bloc d'essai avec une déclaration de capture qui a explicitement réduit l'exception (semblable à votre exemple, sauf qu'ils n'ont pas eu de codes "NullpointeException", mais plutôt juste tronqué la cause de la stacktrace).
@David - J'envisageai sérieusement passer à un autre produit. En supprimant délibérément, des informations d'exception comme celle-ci incombent à l'intérêt supérieur de leurs clients / utilisateurs. Trouvez un autre fournisseur qui ne fait pas ce genre de chose de merde.
Je ne peux que penser que 2 raisons pour lesquelles E.PrintStackTrace () pourrait produire uniquement la chaîne "java.lang.nullpointereException" . .
setstacktrace (nouveau StackTraceElement [0]) à l'exception.
printstacktrace () ou une autre méthode pour renvoyer des informations trompeuses.
Ceci est Beacause Java fait une optimisation du code lorsqu'elle est exécutée en mode serveur (Java -server)
ignorer cela. Utilisez -xx: -omittstacktraceinffastthrow dans java args
Voir le lien ci-dessous pour plus de détails:
Au lieu de désactiver cette optimisation sur un serveur de production, je voudrais simplement suivre les conseils de Peter et regarder une erreur antérieure dans le journal.
Je suis d'accord que vous pouvez faire lorsque vous possédez le code, si vous dépendez de quelqu'un d'autre, jusqu'à ce qu'ils corrigent, c'est le meilleur que vous puissiez faire.
C'est certainement ce qui a provoqué le problème similaire pour moi sur Prod. Merci pour la réponse!
Cela existe sur OpenJDK7 mais pas sur OpenJDK8.
Quelqu'un a-t-il des idées sur la manière dont je peux capturer la trace complète de la pile à une chaîne? p>
Vous pouvez utiliser le moyen ci-dessous (StringWriter.tostring ()) pour transférer la trace de la pile dans une chaîne. P>
StringWriter writer = new StringWriter(); e.printStackTrace( new PrintWriter(writer,true )); System. out.println("exeption stack is :\n"+writer.toString());
Assurez-vous d'utiliser E.PrintStackTrace (), au lieu de E.getstackTrace ();
On dirait que le tableau StackTraceElement dans NPE est en train de se réinitialiser pour vider. Est-ce que quelque chose appelle SsteStackTrace sur le NPE?
@Dangravell - Non, rien ne devrait appeler SsteStackTrace.
Êtes-vous capable de déboguer cela dans une IDE? Pourrait valoir la peine de définir un point d'arrêt dans le bloc de capture pour voir si l'exception est «parfaitement formée».
Ajoutez la sortie enregistrée de votre
myMethod () ou de votre méthode réelle.E.PrintStackTrace (); normalement doit imprimer la trace de remplissage.