In Objective-C perché dovrei verificare se self = [super init] non è zero?

Ho una domanda generale sulla scrittura di metodi init in Objective-C.

Vedo ovunque (codice Apple, libri, codice open source, ecc.) Che un metodo init dovrebbe verificare se self = [super init] non è zero prima di continuare con l'inizializzazione.

Il modello Apple predefinito per un metodo init è:

- (id) init
{
    self = [super init];

    if (self != nil)
    {
        // your code here
    }

    return self;
}

Perché?

Voglio dire, quando mai mai init restituirà zero? Se ho chiamato init su NSObject e ho ottenuto zero, allora qualcosa deve essere davvero fregato, giusto? E in quel caso, potresti anche non scrivere nemmeno un programma ...

È davvero così comune che un metodo init di una classe possa restituire zero? In tal caso, in quale caso e perché?

Per esempio:

[[NSData alloc] initWithContentsOfFile:@"this/path/doesn't/exist/"];
[[NSImage alloc] initWithContentsOfFile:@"unsupportedFormat.sjt"];
[NSImage imageNamed:@"AnImageThatIsntInTheImageCache"];

... e così via. (Nota: NSData potrebbe generare un'eccezione se il file non esiste). Ci sono alcune aree in cui la restituzione di zero è il comportamento previsto quando si verifica un problema, e per questo motivo è prassi normale verificare quasi sempre lo zero, per motivi di coerenza.

Questo particolare linguaggio è standard perché funziona in tutti i casi.

Mentre non comune, ci saranno casi in cui ...

[super init];

... restituisce un'istanza diversa, quindi richiede l'assegnazione a sé.

E ci saranno casi in cui restituirà zero, richiedendo quindi il controllo zero in modo che il codice non tenti di inizializzare uno slot variabile di istanza che non esiste più.

La linea di fondo è che è il modello corretto documentato da usare e, se non lo stai usando, lo stai facendo in modo sbagliato.

Penso che, nella maggior parte delle classi, se il valore restituito da [super init] è nullo e lo controlli, come raccomandato dalle pratiche standard, e quindi restituisci prematuramente se zero, in pratica la tua app non funzionerà correttamente. Se ci pensate, anche se che se (auto! = Nil) controllo è lì, per il corretto funzionamento della classe, il 99,99% del tempo che effettivamente fate bisogno di sé di essere non-zero. Supponiamo ora che, per qualsiasi motivo, [super init] abbia restituito zero, in pratica il tuo controllo contro zero sta sostanzialmente passando il dollaro al chiamante della tua classe, dove probabilmente fallirebbe comunque, dal momento che presumerà naturalmente che la chiamata fosse riuscito.

Fondamentalmente, quello che sto ottenendo è che il 99,99% delle volte, il if (self! = Zero) non ti compra nulla in termini di maggiore robustezza, dal momento che stai solo passando il dollaro al tuo invocatore. Per essere davvero in grado di gestirlo in modo efficace, in realtà dovresti mettere dei controlli nell'intera gerarchia chiamante. E anche in quel caso, l'unica cosa che ti comprerebbe è che la tua app fallirebbe in modo un po 'più pulito / robusto. Ma fallirebbe comunque.

Se una classe di biblioteca ha deciso arbitrariamente di restituire zero come risultato di un [superiniziale], sei comunque praticamente fottuto, e questo è più un'indicazione che lo scrittore della classe di biblioteca ha fatto un errore di implementazione.

Penso che questo sia più un suggerimento di codifica legacy, quando le app venivano eseguite in una memoria molto più limitata.

Ma per il codice di livello C, in genere verificherei comunque il valore di ritorno di malloc () rispetto a un puntatore NULL. Considerando che, per Objective-C, fino a quando non troverò prove contrarie, penso che in genere salterò i controlli if (self! = Zero). Perché la discrepanza?

Perché, a livello C e malloc, in alcuni casi è possibile recuperare parzialmente. Mentre penso in Objective-C, nel 99,99% dei casi, se [superiniziale] restituisce zero, in pratica sei fottuto, anche se provi a gestirlo. Potresti anche lasciare che l'app si blocchi e gestire le conseguenze.

Questo è una specie di riassunto dei commenti sopra.

Diciamo che la superclasse ritorna nil. Che succederà?

Se non segui le convenzioni

Il tuo codice andrà in crash nel mezzo del tuo initmetodo. (a meno initche non faccia nulla di significativo)

Se segui le convenzioni, non sapendo che la superclasse potrebbe restituire zero (la maggior parte delle persone finisce qui)

Il tuo codice è destinato a bloccarsi ad un certo punto in seguito, perché la tua istanza è nil, dove ti aspettavi qualcosa di diverso. Oppure il tuo programma si comporterà inaspettatamente senza crash. Oh caro! Vuoi questo? Non lo so...

Se segui le convenzioni, consenti volentieri alla tua sottoclasse di restituire zero

La documentazione del codice (!) Dovrebbe indicare chiaramente: "restituisce ... o zero" e il resto del codice deve essere preparato per gestirlo. Adesso ha senso.

In genere, se la tua classe deriva direttamente da NSObject, non sarà necessario. Tuttavia, è una buona abitudine entrare, come se la tua classe derivi da altre classi, i loro inizializzatori potrebbero tornare nile, in tal caso, il tuo inizializzatore può quindi catturarlo e comportarsi correttamente.

E sì, per la cronaca, seguo le migliori pratiche e le scrivo su tutte le mie lezioni, anche su quelle derivanti direttamente NSObject.

Hai ragione, spesso potresti semplicemente scrivere [super init], ma non funzionerebbe per una sottoclasse di qualsiasi cosa. Le persone preferiscono semplicemente memorizzare una riga di codice standard e usarla sempre, anche quando è solo a volte necessario, e quindi otteniamo lo standard if (self = [super init]), che prende sia la possibilità di restituire zero sia la possibilità di un oggetto diverso dalla selfrestituzione in considerazione.

Un errore comune è scrivere

self = [[super alloc] init];

che restituisce un'istanza della superclasse, che NON è ciò che si desidera in un costruttore / init di una sottoclasse. Si ottiene indietro un oggetto che non risponde ai metodi della sottoclasse, che può essere fonte di confusione, e generare errori di confusione sulla mancata risposta a metodi o identificatori non trovati, ecc.

self = [super init]; 

è necessaria se la classe super-ha membri (variabili o altri oggetti) per inizializzare prima prima di impostare i membri delle sottoclassi. Altrimenti il ​​runtime objc li inizializza tutti su 0 o su zero . (a differenza dell'ANSI C, che spesso alloca blocchi di memoria senza cancellarli affatto )

E sì, l'inizializzazione della classe base può fallire a causa di errori di memoria insufficiente, componenti mancanti, errori di acquisizione delle risorse, ecc. Quindi un controllo per zero è saggio e richiede meno di pochi millisecondi.

Questo per verificare che l'intializzazione abbia funzionato, l'istruzione if restituisce vero se il metodo init non ha restituito zero, quindi è un modo per verificare che la creazione dell'oggetto abbia funzionato correttamente. Poche ragioni a cui riesco a pensare che init potrebbe fallire, forse è un metodo init inverso che la superclasse non conosce o qualcosa del genere, non penso che sia così comune. Ma se succede, è meglio che non accada un incidente che suppongo, quindi è sempre controllato ...

In OS X, non è altrettanto probabile -[NSObject init]che fallisca a causa di motivi di memoria. Lo stesso non si può dire per iOS.

Inoltre, è buona norma scrivere quando si esegue una sottoclasse di una classe che potrebbe tornare nilper qualsiasi motivo.