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方法，其标志性的意义就是：程序执行到这里就是错误的，例如：
1700439980
1700439981
public void doSomething（）{
1700439982
1700439983
int i=7；
1700439984
1700439985
while（i＞7）{
1700439986
1700439987
/*业务处理*/
1700439988
1700439989
}
[
上一页 ]
[ :1.70043994e+09 ]
[
下一页 ]