6.3 断言与防御式编程

1.回忆:设计ADT

第一个防御:让bug不可能出现
最好的防御就是不要引入bug
静态检查:通过在编译时捕获bug来消除许多bug。
动态检查:Java使数组溢出错误不可能捕获他们动态。如果尝试在数组或列表的边界之外使用索引，那么Java会自动产生错误。——未检查的异常/运行时错误
不可变:不可变类型是一种类型，它的值一旦创建就永远不会改变。
不可变值:由final，它可以被分配一次，但从来没有重新分配。
不可变的引用:通过final，这使得引用不可重新分配，但是引用指向的对象可以是可变的或不可变的

第二道防线:本地化bug
如果无法避免bugs，尝试着将bug限制在最小的范围内
限定在一个方法/小模块内部，不扩散
尽快失败，就越容易发现、越早修复
应该尽可能早的指出client的bug (输入存在错误)

断言：利用断言，Fail fast，避免扩散
检查前置条件是防御式编程的一种典型形式

2.断言

(1)什么是断言，为什么断言?

什么是断言
断言：在开发阶段的代码中嵌入，检验某些“假设”是否成立。若成立，表明程序运行正常，否则表明存在错误。
-当断言为真时，意味着一切都按预期运行。
-当它为false时，意味着它在代码中检测到一个意外错误。

每个断言包含一个布尔表达式，您相信该表达式将在程序执行时为真。如果不为真，JVM将抛出一个AssertionError。出现AssertionError，意味着内部某些假设被违反了。增强程序员对代码质量的信心：对代码所做的假设都保持正确

断言即是对代码中程序员所做假设的文档化，也不会影响运行时性能(在实际使用时，assertion可以被disabled)

断言通常有两个参数
一个布尔表达式，描述假设应该是正确的
-一个显示的信息，如果为假。

Java语言有两个形式的关键字assert:
– assert condition;
– assert condition : message;

-这两个语句对条件求值，如果布尔表达式的值为false，则抛出AssertionError。
在第二个语句中，表达式被传递给的构造函数AssertionError对象，并转换为消息字符串。当断言失败时，描述将在错误消息中打印出来，因此可以使用它向程序员提供有关失败原因的额外细节。所构造的message在发生错误时显示给用户，便于快速发现错误所在

为什么使用断言?
▪文档和测试程序员的假设，例如，不变量;▪验证程序员的理解
▪快速发现漏洞
▪增加对程序没有bug的信心
▪断言将黑盒测试变成白盒测试

经验表明，在编程时编写断言是检测和纠正错误的最快速、最有效的方法之一。
另外一个好处是，断言可以记录程序的内部工作，增强可维护性。

(2)什么该断言，什么不该断言?

何时使用断言?
断言可用于验证:
——内部不变量:断言一个值是在一定的约束条件,例如,断言x > 0。
——表示不变量:断言,一个对象的状态是在约束。一个类的每个实例在执行方法之前或之后必须是什么?类不变量通常通过私有布尔方法验证，如checkRep()。
——控控制流不变量:断言不会达到一定位置。例如，switch-case语句的默认子句。
——方法的前置条件:调用方法时,必须真正的什么?通常用方法的参数或对象的状态表示。
——方法的后置条件:什么方法成功完成后一定是真的吗?

断言什么?
▪前置条件:方法参数要求
▪后置条件:方法返回值要求
-这种断言有时被称为自检。
▪控制流程:覆盖所有
-如果条件语句或 switch不能涵盖所有可能的情况，使用断言阻止非法情况是一个良好的做法。

void foo() {for (...) {if (...)return;
}
assert false; 
// Execution should never reach this point!
}

switch (vowel) { case 'a': case 'e': case 'i': case 'o': case 'u': return "A"; default: assert false; 
}

但是不要在这里使用assert语句，因为它可以被关闭。相反，在非法的情况下抛出一个异常，这样检查将总是发生：

default: throw new AssertionError("must be a vowel, but was: " + vowel);

更多的场景
▪只有输入变量的值是不改变的方法
▪指针是非空的
▪传递到方法中的数组或其他容器可以包含至少X个数据元素
▪一个表已经初始化，以包含真实的值
▪当一个方法开始执行(或完成)时，容器是空的(或满的)
▪结果，从一个高度优化、复杂的方法匹配的结果，从一个缓慢但清楚地编写的例行程序

什么时机使用断言
断言主要用于开发阶段，避免引入和帮助发现bug
实际运行阶段，不再使用断言
避免降低性能
使用断言的主要目的是为了在开发阶段调试程序、尽快避免错误

什么不能断言?
运行时断言不是免费的，它们会使代码混乱，因此必须谨慎地使用
避免琐碎的断言，就像避免不提供信息的评论一样。

// don't do this: 
x = y + 1; 
assert x == y+1;

这个断言不会发现代码中的bug。
此断言不会有助于在代码中发现错误，只会发现编译器或Java虚拟机中的bug，没有意义（除非你怀疑compiler/JDK中、第三方组件中存在错误）
如果一个断言在其本地上下文中很明显，则应忽略

避免在断言中放入可执行代码
▪由于断言可能被禁用，程序的正确性不应该取决于是否执行断言表达式。
▪特别地，声称的表达不应有副作用。例如，如果你想断言一个从列表中删除的元素确实在列表中找到了，不要这样写:
▪如果禁用断言，则跳过整个表达式，并且永远不会从列表中删除x。改为这样写：

// don't do this: 
assert list.remove(x);// do this: 
boolean found = list.remove(x); 
assert found;

不要断言外部条件
程序之外的事，不受你控制，不要乱用断言
文件/网络/用户输入等
断言只是检查程序的内部状态是否符合规约
断言一旦false，程序就停止执行
外部失败不是bugs，你的代码无法保证不出现此类外部错误
外部失败要使用Exception机制去处理

在不同的阶段打开/关闭断言
许多断言机制被设计成只在测试和调试期间执行断言，并在将程序发布给用户时关闭断言。
Java缺省关闭断言，要记得打开(-ea)
断言非常影响运行时的性能
例如，一个程序，搜索一个数组使用二进制搜索有一个要求，数组是排序。
-确定这个要求需要扫描整个数组，然而，将一个应该在对数时间内运行的操作变成一个需要线性时间的操作。
-你应该愿意在测试期间支付这笔费用，因为它使调试更容易，而不是在程序发布给用户之后

在JUnit中assert vs. assertXXX()
▪Java断言语句是一种不同于JUnit方法assertTrue()、assertEquals()等的机制。
▪他们都断言一个关于你的代码的谓词，但被设计用于不同的上下文中。
▪assert语句应该在实现代码中使用，用于实现内部的防御检查。
▪JUnit assertXXX()方法应该在JUnit测试中使用，以检查测试的结果。
▪assert语句不运行没有-ea，但JUnit assertXXX()方法总是运行。

(3)使用断言的指南

断言vs异常
断言通常涵盖程序的正确性问题。
-如果一个断言是一个异常的条件，纠正行动不仅仅是处理错误优雅-纠正行动是改变程序的源代码，重新编译，并发布一个新的版本的软件。断言→Correctness

异常通常包括程序的健壮性问题。
-如果错误处理代码用于处理异常情况，错误处理将使程序优雅地响应错误。错误/异常处理→Robustness

断言在大型复杂程序和高可靠性程序中特别有用。
-它们使程序员能够更快地排除不匹配的接口假设、修改代码时出现的错误等等。

使用异常来处理你“预料到可以发生”的不正常情况，使用断言处理“绝不应该发生”的情况

应该断言前置/后置条件吗?
在其他一些开发者眼里，不应该针对参数的合法性使用断言。

原因：
不管是否-ea，
spec中的pre-/post-conditions都应该被遵守和保证
即使spec被违反，也不应通过assert直接fail，而是应抛出具体的runtime异常

对前置/后置条件使用断言
如果参数来自于外部（不受自己控制），使用异常处理

如果来自于自己所写的其他代码，可以使用断言来帮助发现错误（例如postcondition就需要）

按照惯例，public方法上的前置条件是通过抛出特定的、指定的异常的显式检查来进行的

可以使用断言来测试非公共方法的前置条件，当认为无论client对该类做什么，这些前置条件都正确时（正确性不由client决定）

在public和nonpublic方法中，都可以用断言来处理后置条件

断言和异常处理都可以处理同样的错误

开发阶段用断言尽可能消除bugs，在发行版本里用异常处理机制处理漏掉的错误

3.防御性编程

什么是防御性编程?
防御性编程是一种防御性设计形式，目的是确保软件在不可预见的情况下继续发挥作用。
-防御性编程实践通常用于高可用性、安全性或安全性需要的地方。
▪这一想法可以看作是减少或消除的前景
具有作用的墨菲定律。
▪“你的代码应该尽早失败!”
墨菲定律：如果事情有变坏的可能，不管这种可能性有多小，它总会发生。
这个想法是基于防御性驾驶
-你采取的心态，你永远不知道其他司机会怎么做。
这样的话，如果他们做了危险的事情，你就不会受伤了。
-即使可能是对方司机的错，你也要承担保护自己的责任。

4.防御性编程的技术

防御性编程的技术
▪保护程序从无效输入
▪断言
▪例外
▪具体的错误处理技术
▪街垒
▪调试援助

最好的防御形式是在最初就不要引入错误
您可以将防御性编程与其他技术结合使用。

（1）保护程序不受无效输入的影响

对于生产软件来说，无用输入和无用输出是不够的。
一个好的程序永远不会输出垃圾，不管它接收了什么。
-“垃圾进，无所出”
-“垃圾输入，错误信息输出”
-“垃圾禁止入内”
“垃圾输入，垃圾输出”是一个草率，不安全的程序的标志

对来自外部的数据源要仔细检查，例如：文件、网络数据、用户输入等
当从文件、用户、网络或其他外部接口获取数据时，请检查以确保数据位于允许的范围内
例如：
-确保数值在允许范围内，字符串足够短，便于处理。
-如果一个字符串打算表示一个受限范围的值(例如金融交易ID或类似的东西)，确保该字符串对其预期用途是有效的;否则拒绝它。
-如果您正在开发一个安全的应用程序，请特别警惕可能攻击系统的数据:试图缓冲区溢出、注入SQL命令、注入html或XML代码、整数溢出，等等

对每个函数的输入参数合法性要做仔细检查，并决定如何处理非法输入
-检查例程输入参数的值基本上与检查来自外部来源的数据相同，除了数据来自另一个例程而不是来自外部接口。

决定如何处理不良输入
一旦你检测到一个无效的参数，你会怎么做?
-根据不同的情况，您可以选择十几个不同的方法中的任何一个，这些方法将在本章后面详细描述。

(2)设置路障

隔栏是一种容损策略，起到防火墙的作用

为防御性编程设置障碍的一种方法是指定某些接口作为“安全”区域的边界。检查跨越安全区域边界的数据是否有效，如果数据不有效，则做出明智的反应。

定义一些使用脏数据的软件部分和一些使用干净数据的软件部分可以有效地减轻大多数代码检查坏数据的责任

类的public方法接收到的外部数据都应被认为是dirty的，需要处理干净再传递到private方法——隔离舱
一旦数据被类的public方法接受，类的private方法就可以假定数据是安全的。

操作间技术
-数据在进入手术室前进行消毒。手术室里的任何东西都被认为是安全的。
关键的设计决策是决定在手术室放什么，不放什么，门放在哪里——哪些程序在安全区内，哪些在安全区外，哪些程序对数据进行消毒。
-最简单的方法通常是在外部数据到达时进行消毒，但数据通常需要在多个级别进行消毒，因此有时需要进行多个级别的消毒。

在输入时将输入数据转换为适当的类型
-输入通常以字符串或数字的形式到达。
-有时值会映射到布尔类型，如“yes”或“no”。
-有时候值会映射到一个枚举类型，比如Color_Red，Color_Green, Color_Blue。
在程序中携带可疑类型的数据会增加程序的复杂性，并增加有人通过输入“是”之类的颜色而使程序崩溃的几率。
-输入数据后尽快转换为适当的形式。

路障与断言之间的关系
使用barricades明确区分了断言和错误处理。
-在路障之外的例程应该使用错误处理，因为对数据做任何假设是不安全的。
-街垒内部的例程应该使用断言，因为传递给它们的数据应该在穿过街垒之前进行消毒。如果其中一个程序检测到错误数据，那是程序中的错误而不是数据中的错误。

“隔离舱”外部的函数应使用异常处理，“隔离舱”内的函数应使用断言
-使用barricades也说明了在架构级别决定如何处理错误的价值。
决定哪些代码在路障内，哪些在路障外是一个架构级别的决定。

Proxy设计模式？——隔离

5.防御性编程的检查表

对防御性编程保持警惕
过多的防御性编程会产生自身的问题
增加了复杂性、运行时间和维护成本
防御性代码本身也有可能存在缺陷
还有一个风险是，代码会捕获或防止过多的异常，从而可能导致未被注意的、不正确的结果。
设计好何处进行防御，制定相应的防御策略

检查表:防御性编程
一般
程序是否保护自己不受错误输入数据的影响?
你是否使用断言来记录假设，包括前置条件和后置条件?
断言是否只用于记录不应该出现的条件?
架构或高层设计是否指定了一组特定的错误处理技术?
架构或高层设计是否指定了错误处理应该支持健壮性还是正确性?
是否已经设置了障碍来遏制错误的破坏性影响，并减少需要关注abo的代码数量？
代码中是否使用了调试辅助工具?
是否使用了信息隐藏来包含更改的效果，以便它们不会影响已更改的例程或类之外的代码?
调试辅助工具是否安装在这样一种方式，它们可以激活或停用，而没有太多的麻烦?
防御程序代码的数量是否合适——既不太多也不太少?
在开发过程中，你是否使用过攻击性的编程技术，使错误难以忽略?

异常
你的项目是否定义了异常处理的标准化方法?
你是否考虑过使用异常的替代方法?
错误是本地处理，而不是抛出一个非本地异常，如果可能?
代码避免了在构造函数和析构函数中抛出异常吗?
对于抛出异常的例程来说，所有异常都在适当的抽象级别上吗?
每个异常是否包含所有相关的异常背景信息?
代码是否没有空捕获块?(或者如果一个空捕获块确实是合适的，是否有文档记录?)

安全问题
检查错误输入数据的代码是否检查试图的缓冲区溢出、SQL注入、html注入、整数溢出和其他恶意输入?
是否检查了所有的错误返回码?
所有的例外都被捕获了吗?
错误讯息是否避免提供有助攻击者侵入系统的资料?

6.SpotBugs工具

早期版本：FindBugs
FindBugs：Java静态代码分析工具
-它操作Java字节码
潜在错误分为四类:最可怕的、可怕的、令人不安的和令人担忧的。这是对开发人员可能产生的影响或严重性的暗示。

SpotBugs
SpotBugs是一个使用静态分析来查找Java代码中错误的程序。
-它是FindBugs的精神继承者，在社区的支持下从它离开的地方继续发展。（用爱发电）
它检查超过400个bug模式
它可以独立使用，也可以通过几个集成使用，包括:Ant、Maven、Gradle和Eclipse

7.总结

▪会议：设计ADT
▪断言
-什么该断言，什么不该断言?
-使用断言的指引
▪防御性编程
▪防御编程技术
▪防守型编程检查表
▪SpotBugs工具