Je viens de lire sur la façon d'échouer correctement dans une méthode init et les docs semblent être en désaccord les uns avec les autres. L'un recommande de lancer une exception tandis que les autres recommandent de nettoyer et de revenir à zéro. Quelle est la meilleure pratique actuelle ici?[self release], [self dealloc] ou [super dealloc] dans les méthodes init?
Je crois que la pratique généralement acceptée est de retourner zéro en cas de défaillance. Mais vous ne voulez libérer l'auto pour éviter une fuite:
-(id)init
{
if (self = [super init]) {
...
if (thingsWentWrong) {
[self release];
return nil;
}
...
}
return self;
}
La méthode que j'ai toujours utilisée est le nettoyage et le retour de zéro. Les trois méthodes que vous mentionnez dans le titre de votre question peuvent entraîner des erreurs de segmentation plus élevées dans la hiérarchie des appels, alors que le retour nul ne le fera pas. Je crois que les docs d'Apple eux-mêmes disent de revenir en échec. Où trouvez-vous des divergences?
Le fait de renvoyer simplement zéro entraînera une fuite de mémoire, car l'appel à alloc aura créé un objet avec un nombre de rétention de un. –
La fuite de mémoire est ce que je veux éviter. – Kevin
Liens vers docs: détection d'erreur pendant l'initialisation - http://tr.im/mlyA La mise en œuvre d'un Initializer - http://tr.im/mlyX Vous remarquerez que, dans l'exemple de code dans le second lien ils recommandent de lancer une exception à la place. Je suis à peu près sûr que ce n'est pas la meilleure pratique actuelle. – Kevin
philosophie de cacao sur les exceptions est qu'ils ne doivent être jetés dans des situations programmeur erreurs, comme en passant un argument illégal d'une méthode. Si quelque chose d'autre ne va pas, la méthode devrait juste retourner NO ou nil, et nous espérons signaler les détails via un paramètre NSError ** "out".
Ceci inclut les méthodes -init. Si la situation d'erreur est quelque chose qui pourrait légitimement se produire dans le produit fini, alors la méthode devrait se libérer (pour éviter une fuite) et revenir à zéro.
Les bonnes solutions (exceptions et/ou [self release]; return nil;) ayant été couvertes, j'aborderai les solutions incorrectes. Ne pas envoyer dealloc directement. C'est le travail de release. (Et si votre code fonctionne sous GC, dealloc est inapplicable, et je ne pouvais que spéculer sur les problèmes que l'appel pourrait provoquer.)
Double-ne pas utiliser super pour l'envoyer directement. Cela passerait votre propre implémentation dealloc.
Merci pour les commentaires des gars. C'est ce que je faisais et je pensais être la bonne approche, mais les références aux deux autres méthodes dans les documents m'ont fait penser qu'il pourrait y avoir des cas particuliers à connaître. – Kevin