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

Question

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

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

初始化方法的默认Apple模板是：

- (id) init

{

    self = [super init];

    if (self != nil)

    {

        // your code here

    }

    return self;

}

为什么？

我的意思是init什么时候会返回nil？如果我在NSObject上调用init并返回nil，那么一定要搞砸了，对吧？在这种情况下，您甚至可能根本不编写程序...

类的init方法返回nil真的很常见吗？如果是这样，在什么情况下，为什么？

Answer 1

例如：[[NSData alloc] initWithContentsOfFile:@"this/path/doesn't/exist/"];[[NSImage alloc] initWithContentsOfFile:@"unsupportedFormat.sjt"];[NSImage imageNamed:@"AnImageThatIsntInTheImageCache"];... 等等。（注意：如果文件不存在，NSData可能会引发异常）。在很多地方，出现问题时返回零是预期的行为，因此，出于一致性的考虑，标准的做法是一直不停地检查零。

Answer 2

这个特殊的习惯用法是标准的，因为它适用于所有情况。虽然不常见，但在某些情况下...[super init];...返回一个不同的实例，因此需要分配给self。在某些情况下，它将返回nil，因此需要执行nil检查，以便您的代码不会尝试初始化不再存在的实例变量插槽。底线是使用的已记录的正确模式，如果不使用它，那就错了。

Answer 3

我认为，在大多数类中，如果[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，即使您尝试处理它，也基本上会感到满意。您不妨让应用程序崩溃并处理后果。