防御式编程:理解断言

225849-2f273b05b28aa088

理论部分摘自代码大全

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

断言

断言是指在开发期间使用的、让程序在运行时进行自检的代码。断言为真,则表明程序运行正常;断言为假,则意味着它已经在代码中发现意料之外的错误。
断言可以用于在代码中说明各种假定,澄清各种不希望的情形。
断言主要是用于开发和维护阶段。通常,断言只是在开发阶段被编译到目标代码中。在开发阶段,断言可以查清相互矛盾的假定、预料之外的情况以及传给子程序的错误数据等。

iOS中的断言语法

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

225849-c74332527f38af28
这里举例一段BlocksKit中的代码:

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

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

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

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

通过声明可以发现,断言中会记录当前文件和行号,但是这里赋了默认值,所以使用assert时可以省略。
这里顺带提下代码规范,有些人有时为了方便会把几句代码写在一行。这样写一个潜在的坏处就是如果发生异常,日志中记录了行号。但是因为这一行有几句代码,增加了判断是由具体哪一句代码产生异常。应该避免将几句代码写在一行里。

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

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

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

断言使用的原则

用错误处理代码来处理预期会发生的状况,用断言来处理绝不应该发生的状况

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

避免把执行的代码放到断言中

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

这样写就很危险,应该这样写:

高健壮性的代码,先使用断言再处理错误

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

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

1 收藏 评论

可能感兴趣的话题



直接登录
跳到底部
返回顶部