在Objective-C中，为什么要检查self = [super init]是否不为零？

我有一个关于在Objective-C中编写init方法的一般问题。

我到处都看到（Apple的代码，书籍，开放源代码等），init方法应该在继续初始化之前检查self = [super init]是否不为零。

用于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];

...返回一个不同的实例，因此需要分配给self。

在某些情况下，它将返回nil，因此需要执行nil检查，以便您的代码不会尝试初始化不再存在的实例变量插槽。

底线是使用的已记录的正确模式，如果不使用它，那就错了。

我认为，在大多数类中，如果[super init]的返回值是nil，然后按照标准做法的建议进行检查，然后过早返回（如果为nil），则基本上您的应用仍无法正常工作。如果您考虑一下，即使那里（self！= nil）检查存在，为了使您的班级正常运行，您实际上确实有99.99％的时间需要self不为nil。现在，假设，由于任何原因，[super init] 确实返回了nil，基本上，您对nil的检查基本上是将buck传递给您的类的调用者，无论如何它都可能失败，因为它自然会假设调用为成功。

基本上，我得到的是99.99％的时间，if（self！= nil）不会给您带来任何更大的健壮性，因为您只是将责任推给了调用者。为了真正能够可靠地处理此问题，实际上需要在整个调用层次结构中进行检查。即便如此，它唯一能买到的就是您的应用程序将更加干净/健壮地失败。但是它仍然会失败。

如果一个库类由于[super init]的结果而任意决定返回nil，那么无论如何您都会感到烦恼，这更多地表明该库类的编写者犯了一个实现错误。

我认为当应用程序在有限得多的内存中运行时，这更像是传统的编码建议。

但是对于C级代码，我通常仍将对照NULL指针检查malloc（）的返回值。而对于Objective-C，直到我找到相反的证据，我认为我通常会跳过if（self！= nil）检查。为什么会有差异？

因为在C和malloc级别上，您实际上实际上可以部分恢复。我认为在Objective-C中，在99.99％的情况下，如果[super init]确实返回nil，即使您尝试处理它，也基本上会感到满意。您不妨让应用程序崩溃并处理后果。

这是上面评论的一种总结。

假设超类返回了nil。会发生什么？

如果您不遵守约定

您的代码将在init方法中间崩溃。（除非init无意义）

如果您遵循约定，则不知道超类可能返回nil（大多数人到此为止）

您的代码可能会在以后崩溃，因为您的实例是nil，您期望其中有所不同。否则您的程序将表现出意外而不会崩溃。噢亲爱的！你想要这个吗？我不知道...

如果您遵循约定，则愿意让您的子类返回nil

您的代码文档（！）应该清楚地声明：“ returns ... or nil”，并且需要准备其余的代码来处理此问题。现在有道理了。

通常，如果您的类直接从派生NSObject，则不需要。但是，这是一个好习惯，就像您的类是从其他类派生的一样，它们的初始化器可能会返回nil，如果这样，则您的初始化器可以捕获该异常并正确地执行操作。

是的，为了记录在案，我遵循最佳实践并将其写在我的所有班级上，即使是直接来自的班级也是如此NSObject。

没错，您通常可以只写[super init]，但这对于仅包含任何子类的子类都无效。人们更愿意只记住一个标准的代码行，并用它所有的时间，即使它只是有时必要的，因此，我们得到的标准if (self = [super init])，这需要的零返回两者的可能性和对象比其他的可能性self正在返回考虑在内。

一个常见的错误是写

self = [[super alloc] init];

它返回超类的实例，这不是您在子类构造函数/ init中想要的。您将获得一个不响应子类方法的对象，这可能会造成混淆，并会产生关于不响应方法或未找到的标识符等令人困惑的错误。

self = [super init]; 

需要如果超类有成员（变量或其他对象）来初始化第一建立子类成员之前。否则，objc运行时会将它们全部初始化为0或nil。（与ANSI C不同，后者通常分配内存块而根本不清除它们）

是的，由于内存不足错误，缺少组件，资源获取失败等原因，基类初始化可能会失败，因此检查nil是明智的，并且只需不到几毫秒的时间。

这是为了检查初始化是否有效，如果init方法未返回nil，则if语句返回true，因此这是一种检查对象创建是否正确的方法。我能想到的init可能会失败的原因很少，也许是超类不知道的某种init重写的init方法或某种类似的东西，但我认为这并不常见。但是，如果确实发生了，那么最好不要发生我认为的崩溃，因此总是可以检查...

在OS X中，-[NSObject init]由于内存原因它不太可能失败。iOS不能这么说。

同样，在将可能nil由于任何原因而返回的类子类化时，这也是编写的好习惯。