Discussion :

[edogawa]

Bonjour,
une NullPointerException que je trouve bizarre se produit dans le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
public class Tests {
	public static void main(String[] args){
             Test t  = new Test();
	     Integer ts = t!=null?t.getNbr():0;  // ??
        }
}
 
class Test{
		private Integer nbr;
 
		public Integer getNbr() {
			return nbr;
		}
 
		public void setNbr(Integer nbr) {
			this.nbr = nbr;
		}
	}

le probleme vient précisement de cette ligne
Integer ts = t!=null?t.getNbr():0;

En utilisant un if else à la place de l'opérateur ternaire, le code marche !!

[Robin56]

le probleme vient précisement de cette ligne
Integer ts = t!=null?t.getNbr():0;

En utilisant un if else à la place de l'opérateur ternaire, le code marche !!

Je n'ai pas trop compris ta notation mais en même temps j'ai envi de dire : Ne trouves tu pas un if else plus lisible et donc plus compréhensible par autrui ?

PS : Je n'ai pas répondu à la question mais je ne doute pas que d'autre vont y répondre.

[Ivelios]

Dans un premier temps remplace les Integer par des int.
Pour ton problème je pencherais pour un problème de parenthèsage.
Enfin, comme l'a signalé Robin56, un if/else sera plus lisible.

[thelvin]

Pas de parenthésage, mais d'inférence de type.
Un gros problème du mélange opérateur ternaire/inbox-outbox.

En gros, vu qu'une des expressions possibles en résultat de l'opérateur est la constante 0, de type int, qui n'est pas un type objet, alors l'expression dans son ensemble est considérée de type int.

Ce qui fait donc que l'autre résultat de l'opérateur, t.getNbr(), doit être converti au type int. Vu que t.getNbr() est de type Integer, la conversion se fait comme si c'était t.getNbr().intValue()

Or, dans la classe Test, l'Integer nbr n'a jamais été initialisé, il est donc à null. Et appeler intValue() (ou n'importe quoi) sur un pointeur null, lance un NullPointerException.
Voilà voilà.

Correction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Integer nbr = t.getNbr();
if(nbr == null) {
  nbr = 0;
}

Car ce n'est pas t dont nous devons vérifier s'il est null. Il vient d'être construit avec un new. Il ne peut pas possiblement être null. Son membre nbr peut l'être par contre. Et il l'est forcément si on ne l'initialise pas avant.

Suggestion :
- L'opérateur ternaire est le mal
- Mêler l'opérateur ternaire avec des conversions implicites (telles que l'inbox-outbox,) c'est demander à l'ordinateur de te causer autant de problèmes qu'il le peut. (Valable pour tout langage typé.)

[semaphore1984]

Bonjour,

Bien vu thelvin !

Je rajouterais mon grain de sel en disant que l'auto-boxing est à mon sens une entorse aux règles de typage pas digne d'un langage comme java.
C'est vrai que l'opérateur ternaire est une source d'ennuis qu'il est bon d'éviter, mais on peut pardonner son existence dans java, c'était pour ne pas effrayer ceux qui venaient du C/C++, par contre, l'auto-boxing est vraiment une transgression et même si c'était parfois contraignant de faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Integer zero = new Integer(0)

ça avait le mérite de bien montrer que Integer n'est pas un int.
On voit d'ailleurs sur cet exemple que le diagnostic est compliqué.
Je dirais donc que l'auto-boxing, sauf peut être pour initialiser une variable, "est aussi le mal".

Cordialement