Discussion :

[Invité(e)]

Bonjour,

je me demandais s'il était préférable (moins coûteux) d'effectuer un try catch plutôt qu'une série if else pour éviter des nullpointer.

Dans le cadre de processus métier complexe, il m'arrive de manipuler des grappes d'objets d'origines obscures.

afin d'éviter des nullpointer j'effectue avant chaque utilisation d'objet une vérification via un if/else.

le soucis est que je me retrouve avec une série de if/else qui devient à terme assez lourd.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
 
final MonObjet1 obj1 = service.rechercherObjet1();
 
if (obj1 != null) {
 final MonObjet2 obj2 = obj1.getObj2();
 if (obj2 != null) {
   final MonObjet3 obj3 = obj2.getObj3();
   if (obj3 != null) {
      obj3.executeMethode();
 }
}

dans un cas comme celui ci où l'imbrication devient peu lisible, n'est-il pas préférable d'utiliser un try catch ?

Code :

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

1
2
3
4
5
6
7
8
9
10
 
try {
   final MonObjet1 obj1 = service.rechercherObjet1();
   final MonObjet2 obj2 = obj1.getObj2();
   final MonObjet3 obj3 = obj2.getObj3();
   obj3.executeMethode();
} catch (Exception e) {
   log.info("méthode non exécutée sur objet 3 -> conditions non respectées")
   log.info(e.getMessage());
}

merci beaucoup.

[adiGuba]

Salut,


Ce dépend.

Perso je distinguerais deux cas :

• Les valeurs null sont possibles dans certains cas, et il faut proposer une alternative. Dans ce cas il est souhaitable de vérifier les valeurs avant le traitement.
• Les valeurs null ne devrait pas arriver. Dans ce cas autant carrément laisser remonter l'exception (quel intérêt y a t-il à la logger à ce niveau ?)

a++

[Pill_S]

Ce n'est pas vraiment une bonne idée d'utiliser des exceptions pour traiter le flux normal d'exécution. Une exception doit rester exceptionnelle, les runtimeexception sont habituellement utilisées pour signaler une erreur de la part du programmeur (en codant correctement il aurait pu l'éviter), et les autres une erreur n'étant pas de la faute du programmeur (ressource innaccessible, ...).

Si l'imbrication de if/else devient trop lourde, il faut alors envisager d'autres moyens. Il m'est arrivé de coder des choses dans ce style:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Object o = getProperty(obj1, "obj2.obj3");
 
public static Object getProperty(Object o, String path) {
    String[] paths = path.split(".");
    Object current = o;
 
    for(String p : paths) {
        // accéder à la propriété p de l'objet current via reflexion, en gérant les null
    }
 
    return current;
}

pas forcément très performant, mais dans certains cas c'est plus avantageux de faire comme ça

[Invité(e)]

Merci pour vos réponses rapides,

Je suis dans le cas 1 spécifié par adiGuba.

En faite j'ajoute un nouveau fonctionnement à un processus existant.

Il est donc possible que certaines valeurs soient null mais cela ne doit pas générer d'erreurs.

+ si valeur null alors pas de traitement.

Donc dans mon cas je n'ai pas d'autre choix que d'effectuer cette imbrication de vérification.

[adiGuba]

Un try/catch serait envisageable pour alléger le code, mais il faut savoir qu'une exception peut être assez "lourde" lorsqu'elle remonte (à cause de la génération du stacktrace).


A noter que tu peux utiliser une boucle do/while(false) et des break pour stopper dès que tu rencontres un null, afin d'éviter les multiples boucles imbriqués :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
do {
	MonObjet1 obj1 = service.rechercherObjet1();
	if (obj1==null) break;
 
	MonObjet2 obj2 = obj1.getObj2();
	if (obj2==null) break;
 
	MonObjet3 obj3 = obj2.getObj3();
	if (obj3==null) break;
 
	obj3.executeMethode();
 
} while (false);

a++

[professeur shadoko]

et si on aime les curiosités étranges :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
IT : {
       MonObjet1 obj1 = service.rechercherObjet1();
	if (obj1==null) break IT;
 
	MonObjet2 obj2 = obj1.getObj2();
	if (obj2==null) break IT;
 
	MonObjet3 obj3 = obj2.getObj3();
	if (obj3==null) break IT;
 
	obj3.executeMethode();
}
// la suite

etc.. etc...

[jabbounet]

En plus il y'a un inconvénient a un try catch c'est que l'on a pas la certitude du lieu ou s'est posé le problème:

je m'explique, dans l'exemple que tu donne, on ne sait pas si c'est obj1, obj2 ou obj2 qui pose problème (sans compter que Exception est très large).

Code :

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

1
2
3
4
5
6
7
8
9
try {
   final MonObjet1 obj1 = service.rechercherObjet1();
   final MonObjet2 obj2 = obj1.getObj2();
   final MonObjet3 obj3 = obj2.getObj3();
   obj3.executeMethode();
} catch (Exception e) {
   log.info("méthode non exécutée sur objet 3 -> conditions non respectées")
   log.info(e.getMessage());
}

En plus je rejoins adiguba sur le fait que null peut être un valeur acceptable dans certains cas pour indiquer par exemple l'absence d'une donnée.

Exemple un peu simplet:

Code :

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

1
2
3
4
User jean = Service.findUser("jean");
if (jean == null) {
    logger.info("jean n'est pas un utilisateur du service");
}