2012-03-24 21 views
7

Ziemlich einfache Frage:Obj-C: NSError im Initialisierer

Ich habe eine Init-Methode auf meiner Klasse, die das Potenzial hat, falsch zu gehen. Wenn dies der Fall ist, habe ich vor, "null" zurückzugeben, aber ich möchte auch einen Fehler zurückgeben. Ist es eine schlechte Übung, einen NSError ** -Parameter für eine Init-Methode zu haben? Meine Methode Erklärung würde wie folgt aussehen:

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

Vielen Dank, Nick

Antwort

7

Es ist ungewöhnlich, aber ich glaube nicht, dass es unbedingt eine schlechte Praxis. Ich würde den zweiten Teil der Methode nur "Fehler" anstelle von "andError:" nennen. Sie müssen die Teile eines Methodennamens nicht mit 'und' verbinden, und in diesem Fall wird auch der Eindruck vermittelt, dass der Fehler zum Initialisieren des Objekts verwendet wird. machen es einfach:

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

Auch vergessen Sie nicht die zugewiesene Aufgabe zu lösen, wenn Sie planen, etwas anderes (wie nil) zurückzukehren:

- (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

Eines, was ich empfehlen würde, ist IMMER Einstellung Fehler gleich zu Beginn der Methode. Es gibt keine Garantie, dass der Anrufer es auf Null gesetzt hat. – EricS

+4

@EricS Es gibt keinen Grund, den "Fehler" auf "Null" zu setzen, es sei denn, es liegt ein Fehler vor. Der Aufrufer sollte niemals auf den Wert von @ error schauen, es sei denn, die Methode gibt nil zurück. Ansonsten ist ein Fehler. @Caleb, dass der Code überprüfen muss, um sicherzustellen, dass "error" nicht NULL ist, bevor er "* error" zugewiesen wird. – bbum

+0

@bbum Danke - behoben. – Caleb

Verwandte Themen