在编写应用程序时，您总是必须编写 alloc/inits，获取框架类返回的自动释放数据，...
这可能是 70% 的代码，几乎是你编写的每一行代码......
那么...必须如何测试这些返回的对象，以了解这些调用中的每一个是否都返回了正确的对象？
每次调用都测试返回值，如果在预期分配对象的地方得到 nil，则处理异常？让应用崩溃？
这必须怎么做？
【问题讨论】：
标签： iphone objective-c memory-management exception-handling error-handling
如果它是致命的，只需中止 - 考虑针对这种情况使用自定义错误处理程序，以便信息可以帮助您诊断问题。
如果它不是致命的并且您可以继续，请这样做。 “糟糕，该字符串无法转换为某种编码，但这不是一个显示终止符”。
如果您可以并且应该显示一条消息，请这样做。在某些情况下，重新启动可能是显示消息的更安全时间。
Cocoa 中的异常——捕获并处理您必须做的事情，但 Cocoa 异常通常是“不可恢复的”。 C++ 异常很好，但如果您使用的是 ObjC 和 C++，则使用它们可能不会走得太远。最简单形式的问题是异常不能保证安全地跨越图像边界——ObjC 异常是 C++ 异常（在 OS X 64 位和 iOS 中）。
错误参数是另一种方法。相信你已经看到了：:(NSError**)outError
重要的是您了解每种方法的后果并正确编写。
【讨论】：
不必在每次调用返回对象的函数时检查 nil 返回值。重要的是要了解函数何时更有可能返回 nil 对象以及可能对您的应用程序产生什么后果。
与文件系统或网络相关的函数是您经常需要检查 nil 返回值的两种最常见的类型，因为这两个系统的状态通常超出您的控制范围，因此您尝试使用的资源访问可能不可用。一个很好的迹象表明您应该检查 nil 返回值是该函数是否也将 NSError ** 作为参数。
另一方面，例如，每次创建 NSString 或 NSArray 时都检查 nil 是不必要的，因为它返回 nil 的唯一原因是在测试期间是否应该发现某种程序员错误无论如何。
所以我想我的非常笼统的建议是不要检查 nil，当它可能是 nil 的唯一实际方法是如果有程序员错误时，做检查当返回对象由于某些资源不可用（并且超出您的控制）而可能为 nil 时，为 nil。
另外请记住，在 Objective-C 中向 nil 发送消息是可以的，这也消除了在某些情况下进行大量 nil 测试的需要。
【讨论】：