1700439930
1700439931
我们知道防御式编程最核心的一点就是：所有的外部因素（输入参数、环境变量、上下文）都是“邪恶”的，都存在着企图摧毁程序的罪恶本源，为了抵制它，我们要在程序中处处检验，满地设卡，不满足条件就不再执行后续程序，以保护主程序的正确性，处处设卡没问题，但就是不能用断言做输入校验，特别是公开方法。我们来看一个例子：
1700439932
1700439933
public class Client{
1700439934
1700439935
public static void main（String[]args）{
1700439936
1700439937
StringUtils.encode（null）；
1700439938
1700439939
}}
1700439940
1700439941
//字符串处理工具类
1700439942
1700439943
class StringUtils{
1700439944
1700439945
public static String encode（String str）{
1700439946
1700439947
assert str！=null：“加密的字符串为null”；
1700439948
1700439949
/*加密处理*/
1700439950
1700439951
}
1700439952
1700439953
}
1700439954
1700439955
encode方法对输入参数做了不为空的假设，如果为空，则抛出AssertionError错误，但这段程序存在一个严重的问题，encode是一个public方法，这标志着是它对外公开的，任何一个类只要能够传递一个String类型的参数（遵守契约）就可以调用，但是Client类按照规范和契约调用enocde方法，却获得了一个AssertionError错误信息，是谁破坏了契约协定？—是encode方法自己。
1700439956
1700439957
（2）在执行逻辑代码的情况下
1700439958
1700439959
assert的支持是可选的，在开发时可以让它运行，但在生产系统中则不需要其运行了（以便提高性能），因此在assert的布尔表达式中不能执行逻辑代码，否则会因为环境不同而产生不同的逻辑，例如：
1700439960
1700439961
public void doSomething（List list, Object element）{
1700439962
1700439963
assert list.remove（element）：“删除元素”+element+“失败”；
1700439964
1700439965
/*业务处理*/
1700439966
1700439967
}
1700439968
1700439969
这段代码在assert启用的环境下，没有任何问题，但是一旦投入到生产环境，就不会启用断言了，而这个方法也就彻底完蛋了，list的删除动作永远都不会执行，所以也就永远不会报错或异常，因为根本就没有执行嘛！
1700439970
1700439971
以上两种情况下不能使用assert，那在什么情况下能够使用assert呢？一句话：按照正常执行逻辑不可能到达的代码区域可以放置assert。具体分为三种情况：
1700439972
1700439973
（1）在私有方法中放置assert作为输入参数的校验
1700439974
1700439975
在私有方法中可以放置assert校验输入参数，因为私有方法的使用者是作者自己，私有方法的调用者和被调用者之间是一种弱契约关系，或者说没有契约关系，其间的约束是依靠作者自己控制的，因此加上assert可以更好地预防自己犯错，或者无意的程序犯错。
1700439976
1700439977
（2）流程控制中不可能达到的区域
1700439978
1700439979
这类似于JUnit的fail方法，其标志性的意义就是：程序执行到这里就是错误的，例如：
[
上一页 ]
[ :1.70043993e+09 ]
[
下一页 ]