(Source inconnue) dans la trace de pile d'Exception

Arrière-plan

Cette question est liée à Pourquoi Chaîne.valueOf(null) throw un NullPointerException?

Considérons le fragment de code suivant:

public class StringValueOfNull {
    public static void main(String[] args) {
        String.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, Java est la surcharge de méthode résout le ci-dessus invokation à String.valueOf(char[]), qui à juste titre les résultats dans un NullPointerException au moment de l'exécution.

Compilé dans Eclipse et javac 1.6.0_17, c'est la trace de la pile:

Exception in thread "main" java.lang.NullPointerException
        at java.lang.String.<init>(Unknown Source)
        at java.lang.String.valueOf(Unknown Source)
        at StringValueOfNull.main(StringValueOfNull.java:3)

Noter que la trace de la pile ci-dessus est absent de la CLÉ de l'information: il ne PAS ont la signature complète de la valueOf méthode! Il dit seulement String.valueOf(Unknown Source)!

Dans la plupart des situations que j'ai rencontrées, à l'exception des traces de pile de toujours disposer de la signature complète des méthodes qui sont réellement dans la trace de la pile, qui est bien sûr très utile dans l'identification du problème immédiatement, et l'une des principales raisons pourquoi la trace de la pile (qui va sans dire est assez coûteux à construire) est prévue dans la première place.

Et pourtant, dans ce cas, la trace de la pile ne permet pas à tous. Il a lamentablement échoué à aider le programmeur à identifier le problème.

Est aussi, je peux voir les 3 façons qu'un programmeur peut identifier le problème avec l'extrait ci-dessus:

  • Programmeur réalise sur son propre que la méthode est surchargée, et par la résolution de la règle, le "mauvais" surcharge est appelé dans ce cas
  • Programmeur utilise une bonne IDE qui lui permet de voir rapidement la méthode qui est sélectionné
    • Dans Eclipse, par exemple, la souris-planant sur l'expression ci-dessus rapidement dit programmeur que le String valueOf(char[] data) est en effet celui qui est sélectionné
  • Programmeur examine le bytecode (pouah!)

La dernière option est probablement la moins accessible, mais, bien sûr, est la Réponse Ultime (un programmeur peut faire mal compris la surcharge de la règle, l'IDE peut être buggé, mais bytecode toujours(?) dire la vérité sur ce qui est fait).


Les questions

  • Pourquoi est la trace de la pile, donc peu utile dans ce cas en ce qui concerne les signatures des méthodes qui sont réellement dans la trace de la pile?
    • Est-ce dû au compilateur? Le moteur d'exécution? Quelque chose d'autre?
  • Dans ce que d'autres (rares?) les scénarios peuvent la trace de la pile ne parviennent pas à capturer les informations essentielles comme celle-ci?
  • Notez que le contenu exact d'une trace de la pile n'est pas spécifié dans la JVM spécification ou de la JLS, de sorte que les réalisateurs sont assez libre sur ce qu'ils fournissent. Aussi: mon installation fournit le fichier source et le numéro de ligne dans le stacktrace (c'est l'OpenJDK, cependant), donc je pense que ça dépend de ce que vous utilisez pour exécuter votre code (JRE vs JDK).
  • Waouh je viens de réaliser que j'ai peut-être fait un fou de moi-même ici; à l'exception des traces de pile ne sont JAMAIS inclus la signature de la méthode, apparemment(?). Il ne comprend que le nom de fichier et le numéro de ligne, au mieux. Je vous jure que j'ai vu les signatures trop avant, mais peut-être que je me trompe en quelque sorte. Aurait été agréable, bien que (et devrait être facile à mettre en œuvre, puisque l'information à propos de la signature est plus disponible que le nom du fichier source et le numéro de ligne).
  • y compris la totalité des signatures de méthode serait de faire des traces de pile très difficile à lire.