Objective-Cでself = [super init]がnilでないことを確認する必要があるのはなぜですか？

Objective-Cでのinitメソッドの記述に関する一般的な質問があります。

初期化を続行する前に、initメソッドがself = [super init]がnilでないかどうかを確認する必要があることが、どこでも見られます（Appleのコード、書籍、オープンソースコードなど）。

initメソッドのデフォルトのAppleテンプレートは次のとおりです。

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

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

    return self;
}

どうして？

initがnilを返すのはいつですか？NSObjectでinitを呼び出してnilが返された場合、何かが本当にねじ込まれているはずですよね？そしてその場合、あなたはプログラムを書くことすらできないかもしれません...

クラスのinitメソッドがnilを返すことは本当にありふれたことですか？もしそうなら、どのような場合に、そしてなぜ？

例えば：

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

... 等々。（注：ファイルが存在しない場合、NSDataは例外をスローする可能性があります）。問題が発生したときにnilを返すことが期待される動作である領域はかなり多くあります。そのため、一貫性を保つために、常にnilをチェックするのが標準的な方法です。

この特定のイディオムは、すべてのケースで機能するため、標準です。

珍しいことですが、場合によっては...

[super init];

...別のインスタンスを返すため、自分自身への割り当てが必要です。

そして、それがnilを返す場合があるため、コードが存在しないインスタンス変数スロットを初期化しようとしないようにnilチェックを要求します。

肝心なのは、それが文書化された正しいパターンであり、使用していない場合は間違っているということです。

ほとんどのクラスでは、[super init]からの戻り値がnilであり、標準的な方法で推奨されているようにそれをチェックし、nilの場合は途中で戻ると、基本的にアプリはまだ正常に動作しません。考えてみれば、（self！= nil）チェックがあったとしても、クラスが適切に動作するためには、実際には 99.99％の時間でselfが非nilである必要があります。さて、何らかの理由で[super init] が nilを返したとしましょう。基本的にnilに対するチェックは、基本的にはクラスの呼び出し元に見返りを渡しています。成功した。

基本的に、私が得ているのは、99.99％の確率で、if（self！= nil）が堅牢性の観点から何も購入しないということです。これを確実に確実に処理するには、実際には呼び出し階層全体にチェックを入れる必要があります。そしてそれでも、あなたが買うだろう唯一のものはあなたのアプリがもう少しきれいに/堅牢に失敗するということです。しかし、それでも失敗します。

ライブラリクラスが[super init]の結果としてnilを返すことを恣意的に決定した場合は、とにかくかなりf *** edであり、それはライブラリクラスの作成者が実装の誤りを犯したことを示しています。

アプリがはるかに限られたメモリで実行された場合、これはレガシーコーディングの提案のほうが多いと思います。

ただし、Cレベルのコードの場合は、通常、malloc（）の戻り値をNULLポインターに対してチェックします。一方、Objective-Cの場合、反対の証拠が見つかるまで、if（self！= nil）チェックは通常はスキップします。なぜ矛盾があるのですか？

Cレベルとmallocレベルでは、一部のケースでは実際に部分的に回復できるためです。Objective-Cでは99.99％のケースでは、[super init]がnilを返すと思うのですが、処理しようとしても、基本的にf *** edです。アプリをクラッシュさせて余波に対処することもできます。

これは、上記のコメントの要約のようなものです。

スーパークラスがを返すとしましょうnil。どうなるの？

慣習に従わない場合

initメソッドの途中でコードがクラッシュします。（init意味のないことをしない限り）

あなたが慣習に従っている場合、スーパークラスがnilを返すかもしれないことを知らない（ほとんどの人はここに帰ります）

あなたのインスタンスはnilであるので、あなたのコードは後で何かの時点でクラッシュするでしょう。または、プログラムがクラッシュすることなく予期せず動作することになります。まあ！よろしいですか？知りません...

規約に従えば、サブクラスがnilを返すことを快く許可します

コードのドキュメント（！）には、「returns ... or nil」と明記する必要があり、残りのコードはこれを処理できるように準備する必要があります。今では理にかなっています。

通常、クラスがから直接派生している場合、そのNSObject必要はありません。ただし、クラスが他のクラスから派生しているnilかのように、それらのイニシャライザがを返す可能性があり、そうであれば、イニシャライザがそれをキャプチャして正しく動作できるようになるのは、良い習慣です。

そして、はい、記録のために、私はベストプラクティスに従って、すべてのクラスに書き込みNSObjectます。

あなたは正しい、あなたはしばしば単にを書くことができましたが[super init]、それは何かのサブクラスではうまくいきませんでした。人々は、たった1つの標準的なコード行を記憶し、それをたまにしか必要としない場合でも、常にそれを使用することを好むため、標準が得られますif (self = [super init])。これは、nilが返される可能性とself返される以外のオブジェクトの可能性の両方を取ります。アカウントに。

よくある間違いは書くことです

self = [[super alloc] init];

これはスーパークラスのインスタンスを返しますが、これはサブクラスのコンストラクタ/初期化で必要なものではありません。混乱を招く可能性のあるサブクラスメソッドに応答しないオブジェクトが返され、メソッドや識別子が見つからないなどの応答がないという混乱したエラーが生成されます。

self = [super init]; 

スーパークラスに、サブクラスのメンバーを設定する前に最初に初期化するメンバー（変数またはその他のオブジェクト）がある場合に必要です。それ以外の場合、objcランタイムはそれらをすべて0またはnilに初期化します。（メモリのチャンクをまったくクリアせずに割り当てることが多いANSI Cとは異なります）

そして、はい、基本クラスの初期化は、メモリ不足エラー、コンポーネントの欠落、リソース取得の失敗などが原因で失敗する可能性があるため、nilのチェックは賢明であり、数ミリ秒未満かかります。

これは、初期化が機能したことを確認し、initメソッドがnilを返さなかった場合にifステートメントがtrueを返すため、オブジェクトの作成が正しく機能したことを確認する方法です。initが失敗する可能性があると考えることができるいくつかの理由は、おそらくスーパークラスが認識していないオーバーライドされたinitメソッドまたはそのようなものですが、それほど一般的ではないと思います。しかし、それが起こったとしても、クラッシュが発生したとしても何も起こらないので、常にチェックされます...

OS Xでは、-[NSObject init]メモリ上の理由で失敗する可能性はそれほど高くありません。iOSについても同じことが言えません。

また、nil何らかの理由で返される可能性のあるクラスをサブクラス化する場合は、書くことをお勧めします。