防御式编程：理解断言

理论部分摘自代码大全 理论部分摘自代码大全 在防御式驾驶中要建立这样一种思维，那就是你永远也不能确定另一位司机将要做什么。这样才能确保在其他人做出危险动作时你也不会受到危害。你要承担起保护自己的责任，哪怕是其他司机犯的错误。防御式编程的主要思想是：子程序应该不因传入错误数据而被破坏，哪怕是由其他子程序产生的错误数据。

断言是指在开发期间使用的、让程序在运行时进行自检的代码。断言为真，则表明程序运行正常；断言为假，则意味着它已经在代码中发现意料之外的错误。

断言可以用于在代码中说明各种假定，澄清各种不希望的情形。

断言主要是用于开发和维护阶段。通常，断言只是在开发阶段被编译到目标代码中。在开发阶段，断言可以查清相互矛盾的假定、预料之外的情况以及传给子程序的错误数据等。

在OC中，断言使用NSAssert函数，是一个宏。基本形式是两个参数，第一个参数是一个bool值：断言的结果，第二个参数是一个描述字符串。断言的结果为false时，第二个参数描述字符串会输出。

这里举例一段BlocksKit中的代码：

断言通常用来判断外部输入的参数是否正确，所以cocoa封装了一个检查参数的断言，与NSAssert相比方便的地方就是自动定义了一个输出字符串。

NSParameterAssert是一个封装了NSAssert的宏，定义如下：

在来看上面代码中这句断言的使用：

这段代码的意图是用传入的block来代替某个对应delegate的方法，所以要检查一下传入的block和这个delegate上对应的方法签名是否一致。如果不一致则中断程序，抛出“Incompatible block”提示信息。

在swift中，断言用assert函数。两个参数和OC中的相同。

通过声明可以发现，断言中会记录当前文件和行号，但是这里赋了默认值，所以使用assert时可以省略。

这里顺带提下代码规范，有些人有时为了方便会把几句代码写在一行。这样写一个潜在的坏处就是如果发生异常，日志中记录了行号。但是因为这一行有几句代码，增加了判断是由具体哪一句代码产生异常。应该避免将几句代码写在一行里。

断言还有一个经常使用的地方是单元测试。在单元测试中，XCode中封装了几个在测试中经常使用的断言。

这里列举AFN单元测试中用到了XCTAssert的代码，只截取部分带断言代码：

XCT（Xcode Test）中还有很多类似的断言，有兴趣可以自己查文档，这里就不列举了。

错误处理代码用来检查不太可能经常发生的非正常情况，这些情况在写代码时就预料到的，而且在产品代码中也要处理这些情况。而断言是用于检查代码中的bug，如果在发生异常的时候触发了断言，采取的措施就不仅仅是对错误做出恰当的反应，而是应该修改源码并重新编译。可以把断言理解成一种注释，它说明了这个程序的假定。

断言的可以在编译器中设置关闭，如果你把一些 *** 作写在断言里，在某些情况下可能编译器会过滤掉这些代码。

这样写就很危险，应该这样写：

对于要求高健壮性的代码，可能项目非常庞大，超长的开发周期和很多的开发人员，也可能出现断言被触发但是没有被注意到，这时应该也处理一下触发断言时的错误。

欢迎关注我的微博： @没故事的卓同学

断言的释义：十分肯定地说。 

断言生词详细释义：

十分肯定地说，也指十分肯定地说出的话。断言表示为一些布尔表达式，程序员相信在程序中

的

某个特定点该表达式值为真，可以在任何时候启用和禁用断言验证，因此可以在测试时启用断

言而在部署时禁用断言。同样，程序投入运行后，最终用户在遇到问题时可以重新启用断言。

使用断言可以创建更稳定、品质更好且 不易于出错的代码。

断言也是一种编程术语：

表示为一些布尔表达式。

断言可以有两种形式：

1.assert Expression1.

2.assert Expression1:Expression2.

其中Expression1应该总是一个布尔值，Expression2是断言失败时输出的失败消息的字符串。

如果Expression1为假，则抛出一个 AssertionError，这是一个错误，而不是一个异常，也就

是说是一个不可控制异常（unchecked Exception),AssertionError由于是错误，所以可以不捕

获，但不推荐这样做，因为那样会使你的系统进入不稳定状。

---