(Source inconnue) dans la trace de stack d’exception

Contexte

Cette question est liée à Pourquoi Ssortingng.valueOf (null) lance-t-il une exception NullPointerException?

Considérez l’extrait suivant:

public class SsortingngValueOfNull { public static void main(Ssortingng[] args) { Ssortingng.valueOf(null); // programmer intention is to invoke valueOf(Object), but instead // code invokes valueOf(char[]) and throws NullPointerException } } 

Comme expliqué dans la réponse à la question liée, la surcharge de méthode de Java résout l’invocation ci-dessus à Ssortingng.valueOf(char[]) , qui entraîne à juste titre une NullPointerException au moment de l’exécution.

Compilé dans Eclipse et javac 1.6.0_17 , javac 1.6.0_17 la trace de la stack:

 Exception in thread "main" java.lang.NullPointerException at java.lang.Ssortingng.(Unknown Source) at java.lang.Ssortingng.valueOf(Unknown Source) at SsortingngValueOfNull.main(SsortingngValueOfNull.java:3) 

Notez que la trace de la stack ci-dessus ne contient pas les informations KEY : elle ne possède pas la signature complète de la méthode valueOf ! Il dit juste Ssortingng.valueOf(Unknown Source) !

Dans la plupart des situations que j’ai rencontrées, les traces de stack d’exception ont toujours la signature complète des méthodes qui sont réellement dans la trace de stack, ce qui est bien sûr très utile pour identifier le problème immédiatement et la raison principale dire est assez coûteux à construire) est fourni en premier lieu.

Et pourtant, dans ce cas, la trace de la stack n’aide pas du tout . Il a échoué lamentablement en aidant le programmeur à identifier le problème.

Comme c’est le cas, je peux voir 3 façons dont un programmeur peut identifier le problème avec l’extrait ci-dessus:

  • Le programmeur se rend compte par lui-même que la méthode est surchargée, et par règle de résolution, la “mauvaise” surcharge est invoquée dans ce cas
  • Le programmeur utilise un bon IDE lui permettant de voir rapidement quelle méthode est sélectionnée
    • Dans Eclipse, par exemple, le survol de l’expression ci-dessus indique rapidement au programmeur que la valeur Ssortingng valueOf(char[] data) est bien celle sélectionnée
  • Le programmeur examine le bytecode (pouah!)

La dernière option est probablement la moins accessible, mais bien sûr, la réponse ultime (un programmeur peut mal interpréter la règle de surcharge, l’EDI peut être bogué, mais les bytecodes indiquent toujours la vérité).


Questions

  • Pourquoi la trace de la stack est-elle si peu informative dans ce cas en ce qui concerne les signatures des méthodes qui se trouvent réellement dans la trace de la stack?
    • Est-ce dû au compilateur? Le runtime? Autre chose?
  • Dans quels autres scénarios (rares?) La trace de stack ne parvient-elle pas à capturer des informations essentielles comme celles-ci?

Ceci est normalement lié aux informations de débogage manquantes. Vous utilisez probablement JRE (pas JDK), qui n’inclut pas les informations de débogage pour les classes rt.jar. Essayez d’utiliser le JDK complet, vous obtiendrez des emplacements appropriés dans la trace de la stack:

 Exception in thread "main" java.lang.NullPointerException at java.lang.Ssortingng.(Ssortingng.java:177) at java.lang.Ssortingng.valueOf(Ssortingng.java:2840) at SsortingngValueOfNull.main(SsortingngValueOfNull.java:3) 

Notez que si vous utilisez la génération Ant et que l’atsortingbut debug est défini sur false dans la commande javac, cela peut se produire.

ex: si vous avez besoin d’un emplacement correct dans le jeu de traces debug = true dans la version Ant,

     

J’ai eu le même problème, j’utilise le spring et Apache Ant pour une continuous integration.

L’erreur que j’avais était dans le fichier build.xml.

Le journal des changements de genre avec un contenu plus précis était:

build.xml avec l’erreur:

     

build.xml sans erreur:

     

Dans la structure, il me manquait le courage debug = “true”

J’ai couru le code dans Eclipse et j’ai obtenu la sortie suivante,

 public class Aloof { public static void main(Ssortingng[] args) { Ssortingng.valueOf(null); } } Exception in thread "main" java.lang.NullPointerException at java.lang.Ssortingng.(Ssortingng.java:177) at java.lang.Ssortingng.valueOf(Ssortingng.java:2840) at mysql.Aloof.main(Aloof.java:19) 

Si vous incluez la source complète (à partir de JDK), vous pouvez réellement déboguer sur la ligne 177 dans Ssortingng.java

Cela se produit lorsqu’il n’y a pas d’informations de débogage (ligne) dans la source ou que la machine virtuelle est invitée à renvoyer ces informations au moment du chargement de la classe. Étant donné que vous avez des numéros de ligne, ce n’est pas le paramètre VM mais la classe Ssortingng ne contient pas d’informations de débogage.

Dans Eclipse: Préférences> Java> JRE installés. L’entrée vérifiée doit avoir un chemin à l’intérieur du JDK, par exemple C: \ Program Files (x86) \ Java \ jdk1.7.0_55 \ jre.