Objective-C 中的 NS_BLOCK_ASSERTIONS答案

【问题标题】：NS_BLOCK_ASSERTIONS in Objective-CObjective-C 中的 NS_BLOCK_ASSERTIONS
【发布时间】：2011-09-20 16:10:40
【问题描述】：

我在 iPhone 应用程序中使用 NSAssert() 调用，我对 Apple 文档的理解是，如果定义了 NS_BLOCK_ASSERTIONS，则断言不会编译到代码中。

要关闭断言，我在头文件中声明：#define NS_BLOCK_ASSERTIONS

但是，断言代码似乎仍在运行。

这里有什么我遗漏的吗？

谢谢

约翰

【问题讨论】：

标签： iphone objective-c xcode debugging

【解决方案1】：

正如@dwsolberg 提到的，Xcode 有一个名为ENABLE_NS_ASSERTIONS 的新构建设置。对于新项目，其发布配置的值设置为NO，所有其他配置的值设置为YES。您可以使用此设置以及广泛使用的 NS_BLOCK_ASSERTIONS 方法，该方法在 Xcode 6 中仍然有效。

断言是一种在开发期间跟踪错误的工具，绝不应该在生产代码中触发！此外，只有在绝对必要的情况下才应使用异常，即如果出现了该死的错误以至于程序无法继续执行。 Cocoa 的方式是给关键方法一个布尔返回值，并用一个错误对象对其进行参数化，该错误对象可以在方法内部设置，如果返回值为NO，则可以在外部使用。

希望对一些人有所帮助;-)

【讨论】：

为什么不应该在生产代码中使用断言？这就像允许静默数据损坏而不是崩溃！如果开发人员滥用我的库 API，它应该会崩溃，以便他可以修复它 - 调试或发布。断言有什么特别之处，应该在生产环境中禁用，但允许其他运行时异常？
应用程序不应该崩溃，它应该优雅地处理错误、捕获它们、显示错误并另外通知您的错误跟踪系统。对于图书馆来说也是一样的。您可以发布 lib 的调试版本和发布版本。永远不要让您的应用崩溃
由于应用程序处于未定义状态，因此无法显示不可恢复的错误。不再可能继续执行。
我6年iOS开发从来没有出现过这样的错误，这不应该意味着不可能发生这样的事情。但在这种情况下，您应该过度考虑您的应用程序设计，并在视图层次结构的更高（或最高）级别上显示错误。崩溃是您的应用程序可能发生的最糟糕的事情！抱歉，这完全是错误的。
如果你错过了一个空指针断言并且你向一个 nil 对象发送消息并且你认为一切都很好，会发生什么？结果可能是用户数据损坏。您似乎不了解“未定义状态”的概念。应用程序无法恢复，并且不会出现有意义的错误。这相当于一个编程错误。这就像试图终止一个挂起的工作线程。终止线程后，堆栈未定义，无论主线程是否正常工作，应用程序都必须崩溃。除非后台线程正常返回，否则无法从中恢复。

【解决方案2】：

如果您基于标准模板之一创建了 Xcode 项目，那么 Cocoa 标头（包括包含 NSAssert 宏的 NSException.h）将在项目中的任何其他文件之前进行预处理。因此，任何项目的头文件或实现文件中的#define NS_BLOCK_ASSERTIONS 对NSAssert 宏都没有影响。

尝试将NS_BLOCK_ASSERTIONS 放入目标甚至项目的预处理器宏中（仅用于发布配置）：

或者将#define NS_BLOCK_ASSERTIONS 放在#import <Cocoa/Cocoa.h> 或#import <Foundation/Foundation.h> 行之前的前缀(.pch) 标头中。

【讨论】：

请注意，在 Xcode 4.2 中，模板已经为您设置好了：断言在发布版本中被阻止。
我想它又被改变了。在 Xcode 5.0 中，构建设置下的处理区域包含一个名为“Enable Foundation Assertions”的部分，其中默认启用所有构建配置：AdHoc、Debug 和 Release。
在 Xcode 5.0.2 中，默认情况下对 Release 构建禁用断言。
然而正如prod.lists.apple.com/archives/xcode-users/2013/Oct/… 所指出的，尽管 Xcode 5 中有不同的标志，NSException.h 仍然使用 NS_BLOCK_ASSERTIONS。请参阅我即将评论的问题stackoverflow.com/questions/20377845/…