Que ce soit dans les copies de mes élèves ou dans les programmes de mes collègues, je tombe sans arrêt sur le même bug, à savoir qu’un « Boolean », ça peut prendre trois valeurs…
Que se passe-t-il me demande un collègue au bord des larmes (j’en rajoute pour l’aspect dramatique) ?… Il vient d’écrire le code suivant et le programme lui explose à la tête :
1 2 3 4 5 6 7 8 9 10 11 12 13 | public class SomeClass { private Boolean first; ... public void someMethode() { ... if(first) { ... } else { ... } ... |
Et ça lui envoie une NPE (NullPointerException) alors qu’il a bien appris à l’école qu’un « boolean » ne peut prendre que les valeurs « false » et « true » et que, en Java, la valeur par défaut est « false ».
Et bien non… Il est vrai qu’un « boolean » ne peut prendre que ces deux valeurs, mais un « Boolean » avec un grand « B » n’est pas un type primitif ; c’est un objet. Il peut donc également prendre la valeur « null », qui d’ailleurs est sa valeur par défaut… Ah la la l’autoboxing… C’est tellement injuste…
Notez que je trouve souvent cette erreur dans les « getters modifiés », ce qui est d’autant plus vicieux :
1 2 3 4 5 6 7 8 |
La première fois qu’on tombe sur celui-ci, ça fait mal. Le pire c’est qu’on peut partir d’une variable en « boolean », demander à Eclipse de générer les « getters-setters », puis changer le « boolean » en « Boolean » sans qu’il n’y ait aucune alerte… enfin saut si vous utilisez PMD ou un équivalent…
Bonjour,
Il faut noter que ce problème lié à l’autoboxing peut se produire avec d’autre type primitifs qui ont une représentation Objet (Long, Integer, …). Cette méthode renvoie une NPE sur le return (il vaut avouer qu’une NPE sur un return aussi simple peut surprendre) :
2
3
4
5
6
7
8
{
Long montant = null;
// du code ici qui peut initialiser montant sous certaines conditions
return montant;
}
Romain.
Oui c’est exact, forcément. Mais bizarrement aucun de mes élèves/collègues ne se fait avoir sur les chiffres… Et j’ai le sentiment qu’ils n’utilisent pas du tout les chars…