Acabo de leer sobre cómo fallar correctamente en un método init y los documentos parecen estar en desacuerdo entre sí. Uno recomienda lanzar una excepción mientras que los otros recomiendan limpiar y devolver cero. ¿Cuál es la mejor práctica actual aquí?[self release], [self dealloc] o [super dealloc] en los métodos init?
Creo que la práctica generalmente aceptada es devolver nulo al fallo. Pero usted desea liberar auto para evitar una fuga: la filosofía
-(id)init
{
if (self = [super init]) {
...
if (thingsWentWrong) {
[self release];
return nil;
}
...
}
return self;
}
El método que siempre he utilizado es limpiar y devolver nil. Los tres métodos que menciona en el título de su pregunta pueden ocasionar que los segmentos superiores suban en la jerarquía de llamadas, mientras que los valores nulos no lo harán. Creo que los documentos de Apple dicen que devuelvan nulo en caso de falla. ¿Dónde encuentras discrepancias?
Simplemente devolviendo nil perderá memoria, ya que la llamada a alloc habrá creado un objeto con un conteo de retención de uno. –
La fuga de memoria es lo que quiero evitar. – Kevin
Los enlaces a documentos: Detección error durante la inicialización - http://tr.im/mlyA implementación de un inicializador - http://tr.im/mlyX Se dará cuenta de que bajo el código de ejemplo en el segundo link recomiendan lanzar una excepción en su lugar. Estoy bastante seguro de que esa no es la mejor práctica actual. – Kevin
de cacao sobre las excepciones es que sólo se deben lanzar en situaciones que son programador errores, como pasar un argumento ilegal a un método. Si algo más sale mal, el método debería simplemente devolver NO o nulo, y con suerte informar los detalles a través de un parámetro NSError ** "out".
Esto incluye -init methods. Si la situación de error es algo que podría ocurrir legítimamente en el producto terminado, entonces el método debería liberarse (para evitar una fuga) y devolver cero.
Después de haber cubierto las soluciones correctas (excepciones y/o [self release]; return nil;), abordaré las soluciones incorrectas.
No envíe dealloc directamente. Ese es el trabajo de release. (Y si el código se ejecuta en vez de GC, dealloc no es aplicable, y sólo podía especular sobre cuáles son los problemas que causaría llamando.)
Doble-no uso super para enviar directamente. Eso saltaría su propia implementación dealloc.
Gracias por los comentarios chicos. Esto es lo que estaba haciendo y pensé que era el enfoque adecuado, pero las referencias a los otros dos métodos en los documentos me hicieron pensar que podría haber algunos casos especiales de los que se tenga conocimiento. – Kevin