2012-03-24 13 views
7

Pregunta bastante simple:Obj-C: NSError en el inicializador

Tengo un método init en mi clase que tiene el potencial de salir mal. Si lo hace, planeo "devolver cero", pero también me gustaría devolver un error. ¿Es una mala práctica tener un parámetro NSError ** para un método init? Mi declaración de método se vería así:

- (id) initWithArgs:(NSString*) args andError:(NSError**)error; 

Muchas gracias, Nick

Respuesta

7

Es inusual, pero no creo que sea necesariamente una mala práctica. Sin embargo, nombraría la segunda parte del método como "error" en lugar de "andError:". No es necesario que conecte las partes de un nombre de método con 'y', y en este caso también da la impresión de que el error se está utilizando para inicializar el objeto. Sólo asegúrese de que:

- (id) initWithArgs:(NSString*) args error:(NSError**)error; 

Además, no se olvide de liberar el objeto asignado si va a volver otra cosa (como cero):

- (id) initWithArgs:(NSString*) args error:(NSError**)error 
{ 
    if ((self = [super init])) { 
     if (canInitThisObject) { 
      // init this object 
     } 
     else { 
      [self release]; 
      self = nil; 
      if (error != nil) { 
       *error = [NSError errorWithDomain:someDomain code:someCode: userInfo:nil]; 
      } 
     } 
    } 
    return self; 
} 
+1

Una cosa que recomendaría es la creación SIEMPRE error nada al comienzo del método. No hay garantía de que la persona que llama se haya centrado en cero. – EricS

+4

@EricS No hay ninguna razón para establecer el 'error' en' nil' a menos que haya un error. La persona que llama nunca debe mirar el valor '@ error' a menos que el método devuelva' nil'. Hacer lo contrario es un error. @Caleb que el código necesita verificar para asegurarse de que 'error' no sea NULL antes de asignar' 'error'. – bbum

+0

@bbum Gracias - corregido. – Caleb