Version imprimable
Une des plaies de la programmation objet est l'erreur trop souvent rencontrée :oops: Null object reference.
Il est élégant d'écrire une instruction comme objA.objB.methode ... qui plante si la référence objB n'est pas instanciée. On peut toujours vérifier avant l'appel :
mais c'est déjà beaucoup moins élégant :(Code:
2
C'est plus objet mais pas plus beau avec un try catch.
Avez vous un pattern sympa pour solutionner ce problème ?
Kio,
Oui, elle est même très simple :Citation:
Envoyé par elisfr
- coder proprement
- et pour cela, entre autres, toujours vérifier la validité des pointeurs (ce qui implique de les mettre à NULL quand on libère).
:)
C'est justement le sens de ma question. : comment tester proprement la validité d'une référence (pointeur n'est pas le terme le plus approprié) ?
Kio,
Je ne vois pas ce que tu veux dire par "comment tester proprement la validité".
Il faut comparer à la valeur indiquant l'invalidité NULL, c'est tout.
Maintenant, si, comme tu en parles dans ton premier post, tu penses qu'ajouter des tests dans ton programme n'est pas "élégant", eh bien, il faudra que tu sois moins élégant. :)
(A moins que tu trouves comment faire un test sans en faire... :))
Réponse dans la spécification de la technologie et l'API que tu utilises, et souvent ça donne "==", "equals()" ou autre selon les cas; ça dépend aussi en grande partie de l'application que tu codes.Citation:
comment tester proprement la validité d'une référence
Si tu dois vérifier qu'une référence n'est pas nulle avant chaque manipulation d'objet, soit 90% des instructions, tu n'est pas couché. Il n'y a pas de solution à cela. Tout réside dans la vigilance du programmeur.
Cette exception est un reliquat des temps anciens (C/C++), un langage moderne ne devrait pas autoriser à affecter NULL à un objet. Lorsqu'un calcul peut échouer, il faut que ce soit explicite dans la spécification de ce calcul, et que la prise en compte de l'échec soit obligatoire dans le code utilisant ce calcul.
Un langage comme Haskell permet facilement ce genre de chose, avec un type comme "Maybe a" qui permet d'enrober un type quelconque par une gestion d'échec et n'autorise pas à simplement ignorer cette possibilité.
Le fait que les Null pointer exceptions soient si difficiles à prévoir et à éviter démontre bien qu'il s'agit d'une faille fondamentale dans les langages qui y sont sujets.
--
Jedaï
Oui, tout à fait, et en ce sens les langages fonctionnels ont apporté beaucoup.
Dans le cas de Java, je dirais que ne jamais laisser la possibilité à une référence d'être null permet de s'en sortir. Si un objet n'existe pas, il est inutile de le référencer !
Mais j'ajouterai quelque chose : je ne suis pas sûr, dans le cas de Java, qu'une référence null indique que l'allocation de l'objet a échoué. Si je me souviens bien, c'est une liberté laissée au programmeur que d'initialiser une référence à null... donc si on n'en utilise jamais, il n'y aura jamais de problème.
Il se peut que l'on ait justement oublié une allocation quelque part.Citation:
Envoyé par InOCamlWeTrust
Un exemple, lorsque l'on crée des IHM sous forme d'application Web avec Java, on peut se retrouver à avoir des formulaires de saisis d'utilisateurs et des classes qui représente ce formulaire.
Par exemple, un formulaire de saisi pour la recherche d'une personne pourrait contenir les champs : Integer age; String nom...
Il suffit d'oublier un champs lors de la création du formulaire pour se retrouver avec des références null.
Mais c'est une erreur de programmation dans ce cas, je ne sais pas si tu parlais de ce type de cas.
Dans le cas d'une association avec une cardinalité 0..1 on peut rencontrer une référence nulle. Dans ce cas la référence à nulle porte une signification métier. Toute la difficulté est bien là.
Si une classe A est associée à une classe B avec une cardinalité 0..1 et que l'on instancie un objet de la classe A ; que faut-il faire si cet objet n'est pas associé à un objet de la classe B ?
On est pas dans un cas d'erreur (au sens métier).
On a bien objA != null et objA.objB == null
dans ce cas, le fait que objA.objB != null est une precondition necessaire a l'execution de ton code; et dans ce cas, assert que objA.objB est different de null.
Et il devrait le faire à chaque fois qu'il utilise cet objet ? A mon avis c'est une erreur de design en amont : cet objet qui peut être null ne devrait pas être accessible directement.Citation:
Envoyé par screetch
--
Jedaï
Un article interessant de Handers Heljberg (auteur de C#) qui me semble clore cette discution : il faut attendre la solution dans les prochains langages.
http://www.computerworld.com.au/inde...6074;fp;;fpid;
C'est dans l'idée du pattern "Null Object" : http://en.wikipedia.org/wiki/Null_Object_patternCitation:
Envoyé par elisfr