1700439924
1700439925
断言失败后，JVM会抛出一个AssertionError错误，它继承自Error，注意，这是一个错误，是不可恢复的，也就表示这是一个严重问题，开发者必须予以关注并解决之。
1700439926
1700439927
assert虽然是做断言的，但不能将其等价于if……else……这样的条件判断，它在以下两种情况不可使用：
1700439928
1700439929
（1）在对外公开的方法中
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作为输入参数的校验
[
上一页 ]
[ :1.700439924e+09 ]
[
下一页 ]