selector sur nil, crade ou pas ?

Flo · janvier 2009

Bonjour à tous,

Lorsque j'ai le code suivant :

<br /> [anObject aSelector]; //anObject == nil<br />

Eh ben ça fait rien et ça continue comme si de rien n'était (à l'inverse de certain langage comme java "nul pointer exception"). Donc je me dis, est-ce bien nécessaire d'écrire des trucs genre :

<br /> if (anObject)<br />&nbsp; [anObject aSelector]; //anObject != nil<br /> <br />

Merci d'avance pour vos réponses !

AliGator · janvier 2009

Non ce n'est pas "crade" du tout, c'est tout à fait autorisé en Objective-C, ça fait même partie des features du langage.
Et c'est même très pratique, d'une part pour pas avoir à s'embêter dans certains cas, par exemple pour un "setter" :

-(void)setValue: (Toto*)val {<br />&nbsp; if (value != val) {<br />&nbsp; &nbsp; [value release];<br />&nbsp; &nbsp; value = [val retain];<br />&nbsp; }<br />}

Ici, même si val, la nouvelle valeur qu'on veut donner, est nil, ça ne porte pas à conséquence. De même si value était nil quand on lui envoie le release, bah c'est pas grave, ça fait rien.

C'est un comportement très pratique aussi pour les messages enchaà®nées dans une même ligne :

Toto* objA = [[[[objB msg1] msg2] msg3] msg4];<br />NSString* s = [[[data objectAtIndex: column] valueForKey:@&quot;texts&quot;] objectAtIndex:line];

Ici même si une valeur intermédiaire retourne nil, par exemple si [objB msg1] retourne nil, ça ne plantera pas : on va juste envoyer msg2 à ce "nil" ce qui ne va rien faire (et renvoyer nil à son tour)... jusqu'au bout de la chaà®ne, et du coup objA sera nil à son tour.
(Alors que si on avait, comme dans des langages comme le C ou le C++, à vérifier chaque résultat intermédiaire pour savoir s'il est NULL ou pas, t'imagine le surplus de code :P )

Flo · janvier 2009

Nickel ! merci.

C'est vrai que ce genre de comportement est bien pratique et vu que ça n'a pas d'incidence, pourquoi se priver ?! :adios!:

selector sur nil, crade ou pas ?

Réponses