Discussion :

[nicolas_isi]

Bonjour,

Je me pose un problème d'ordre sémantique sur les types d'exception NullPointerException et IllegalArgumentException.

J'ai une méthode avec en paramètre un objet. Dans le corps de cette méthode je voudrai déclencher volontairement une exception quand ce paramètre est null.
Perso, j'aurai plutôt levé une exception de type NullPointerException. Mais étant donné que c'est un paramètre de ma méthode je me demande s'il ne vaut pas mieux utiliser IllegalArgumentException.

Qu'en pensez vous ?

Nicolas.

[Heimdal]

Salut,

La théorie voudrait plutôt qu'on utilise une NPE dans ce cas là.
Perso, je préfère lever des IAE avec un message clair.
Je suppose que c'est avant tout une question de gout.

Voyons ce qu'en pense les autres.

[thelvin]

Tu veux lancer une exception quand le pointeur est null.
Ça signifie que passer un pointeur null en paramètre de la méthode est une erreur de programmation.
Donc la logique de la chose voudrait que ce soit un NullPointerException.

A priori ce n'est pas vraiment important. J'ai tendance à penser qu'un NullPointerException indique le problème plus directement que ne le ferait un IllegalArgumentException : Object is null. Mais les deux permettent de repérer le soucis, alors pas grave.

[professeur shadoko]

pour moi pas de doute: c'est une IllegalArgumentException.
pourquoi?
à mon humble avis les RuntimeException existent en deux saveurs:
- les vraies RuntimeException qui sont le résultat d'une erreur d'exécution détectée par la machine virtuelle
- les préconditions non remplies qui sont sous la responsabilité du code appelant. IllegalArgumentException et autres.

on peut approfondir la discussion en arguant que dans le premier cas c'est le code réalisant qui est fautif alors que dans le second c'est le code appelant qui ne remplit pas sa part du contrat et donc on le signale dument.
I

[tchize_]

si on suit la logique de l'api java. Quand un argument est incorrect car null, c'est bien souvent le nullpointerexception qui est déclenché. La différence entre le null "prévu" et le null pas vraiment pris en charge se joue dans le message du NPE ainsi que dans la documentation de la méthode précisant qu'elle peut déclencher un NPE

[professeur shadoko]

en fait cela se situe à un autre niveau: ou bien on laisse le NullPointerException se produire (et on dit qu'il y a un risque si on a un argument pas correct) ou bien on ne le laisse pas se produire parceque c'est pas la peine d'aller jusque là.
C'est donc une décision au niveau de la réalisation du code, mais là où j'ai des doutes c'est: est-il pertinent de déclencher soi-même une NullPointerException?
Je ne le pense pas.
Si on fait des contrôles de préconditions je pense qu'il faut bien l'affirmer.

[tchize_]

oui, ca se tiens, mais l'api n'est pas d'accord avec vous, et quand on doute, il vaut mieux suivre les recommandations de sun, car on sait qu'elle seront cohérentes pours l'enesmble des programmeurs java. En l'occurence, on trouve dans la javadoc de NullPointerException,

Thrown when an application attempts to use null in a case where an object is required. These include:

• Calling the instance method of a null object.
• Accessing or modifying the field of a null object.
• Taking the length of null as if it were an array.
• Accessing or modifying the slots of null as if it were an array.
• Throwing null as if it were a Throwable value.

Applications should throw instances of this class to indicate other illegal uses of the null object.

On est bien dans le dernier cas

[professeur shadoko]

Je profite donc de cette tribune pour proposer la classification suivante des Exceptions :

- Exceptions de "pur" Runtime: déclenchés par la machine virtuelle. Non déclarées dans les clauses "throws". En cas de déclenchement c'est le programmeur du code réalisant qui devra faire son autocritique en public.

- Exceptions liées à un non respect des préconditions. Devraient être déclarées dans les clauses "throws" mais le compilo ne force pas le catch. En cas de déclenchement c'est le programmeur du code réalisant qui sera exposé avec un carcan sur la place publique et on aura le droit de lui jeter des canettes de coca et des restes de Pizza.

- Exceptions controlées. déclarées dans les clauses throws et le compilo force l'utiisation de la règle "traiter ou propager". Bon la la ligne du Parti est respectée.

- Les Exceptions OOpsSpecsPourravesException. obligatoirement déclarées dans les clauses "throws" et le compilo emet un warning si on ne les traite pas. Ces Exceptions correspondent au cas où on modifie ultérieurement une API publique (ce qui ne devrait pas être) et sont introduites pour faire plaisir à Anders Hjelmsberg (-le créateur de C#- qui, malgré ses grandes qualités, se fait des idées faussses sur les exceptions).

ça va comme ça?

edit: je persiste et signe pour affirmer qu'un test de précondition ne doit pas propager un NullPointerException.

[tchize_]

edit: je persiste et signe pour affirmer qu'un test de précondition ne doit pas propager un NullPointerException.

Et moi je dit, la première chose a respecter est la spec

[Caalador]

Bonjour,

je ne suis pas d'un niveau suffisant pour parler d' "ordre sémantique", mais par contre, je suis de l'avis de thelvin dans le sens ou le NPE me semble permettre une identification plus rapide du problème.

[Heimdal]

Et moi je dit, la première chose a respecter est la spec

+1

Après je trouve qu'un message clair sur la nullité d'un attribut dans une IAE permet de détecter le problème aussi vite et permet de différencier les erreurs d'utilisation des dev du projet et ceux d'utilisation d'une API.
Donc pour résumer j'aurais tendance à suivre cette logique:

- dev d'une API: NPE (on suit les specs à la lettre)
- dev d'un soft qqcq: IAE

[adiGuba]

Salut,


Pour moi le NPE est le plus précis et le plus clair. Il n'y a pas à chercher midi à 14h !

Bien sûr il faut accompagner cela d'un message clair et explicite du style : "xxxx must not be null".


a++

[professeur shadoko]

he he:ok ok pas taper pas taper! .... et si je fais ceci :

Code :

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

1
2
3
 
class NullParameterException extends NullPointerException {
}

trouverais je grace à vos yeux?
(Mon objectif étant de toujours distinguer les types de RuntimeException: il est vrai que dans ce cas j'aurais plutot tendance à hériter de IllegalArgumentException qui est la vraie sémantique -quoiqu'on en dise-)

[tchize_]

trouverais je grace à vos yeux?

Nan, t'as travaillé comme un cochon en oubliant de redéfinir tous les constructeurs

[adiGuba]

(Mon objectif étant de toujours distinguer les types de RuntimeException: il est vrai que dans ce cas j'aurais plutot tendance à hériter de IllegalArgumentException qui est la vraie sémantique -quoiqu'on en dise-)

Disons que fondamentalement il n'est pas choquant de remonter une IllegalArgumentException... mais que perso dans ce cas précis je m'attendrais plus à une NPE...

Pour moi un IllegalArgumentException survient lorsqu'un argument à une valeur incorrect, alors qu'une référence null représente une "absence de valeur"

Quand à la spécialisation, c'est surtout pratique dans les cas où cela peut entrainer un traitement spécifique.


Mais bon cela reste du chipotage...


@Heimdal : je n'aime pas trop l'idée de différencier API et soft concernant la gestion des exceptions. Il vaut mieux avoir quelque chose de cohérent.

@professeur shadoko : je n'ai pas compris ton passage sur les "OOpsSpecsPourravesException" !?!? C'est une notion spécifique à C# ??


a++

[tchize_]

C'est une notion spécifique à C# ??

Les specs pouraves?

[thelvin]

Que ce soit IllegalArgumentException ou NullPointerException, l'un et l'autre sont "la" vraie sémantique.

Démonstration :
- null n'est pas un paramètre acceptable, donc ça correspond à un IllegalArgumentException.
- L'erreur rencontrée est que ce qui ne peut pas être un pointeur null en est un, donc c'est un NullPointerException.

Conclusion : au niveau sémantique, les deux exceptions sont "la" vraie sémantique. Ce qui ne nous arrange pas car un NullPointerException n'est pas forcément un IllegalArgumentException, et donc n'en hérite pas.

Face à cette réalité un peu gênante, on peut décider plein de choses. Notamment de faire ce qu'on veut. Ou de suivre la convention de la bibliothèque de base Java et la documentation de NullPointerException. Ou de suivre une autre convention.

Mais les deux exceptions sont "la" sémantique correcte.

[Rei Ichido]

Je serai plutôt de l'avis de Tchize, en l'occurrence. La spéc est faite de telle façon qu'on aurait pu imaginer un NullArgumentException héritant de IllegalArgumentException. Ce n'est pas le cas, c'est plutôt une bonne indication sur le fait qu'on est censé utiliser la NullPointerException.

Maintenant, ça ne me choquerai pas de voir un IllegalArgumentException dans ce cas - tout est bien sûr dans le message qui va bien.