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 d' String.valueOf(char[])
, ce qui se traduit légitimement en 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)
Notez que la trace de la pile ci-dessus est absent de la CLÉ de l'information: il n'est PAS de disposer de l'intégralité de la signature de l' valueOf
méthode! Il dit juste qu' 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, ce qui est 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.
Comme je peux voir 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 que le programmeur
String valueOf(char[] data)
est en effet celui qui est sélectionné
- Dans Eclipse, par exemple, la souris-planant sur l'expression ci-dessus rapidement dit que le programmeur
- 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-ce 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?