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
}
1700439990
1700439991
assert false:“到达这里就表示错误”;
1700439992
1700439993
}
1700439994
1700439995
(3)建立程序探针
1700439996
1700439997
我们可能会在一段程序中定义两个变量,分别代表两个不同的业务含义,但是两者有固定的关系,例如var1=var2*2,那我们就可以在程序中到处设“桩”,断言这两者的关系,如果不满足即表明程序已经出现了异常,业务也就没有必要运行下去了。
1700439998
1700439999
1700440000
1700440001
1700440003
编写高质量代码:改善Java程序的151个建议 建议20:不要只替换一个类
1700440004
1700440005
我们经常在系统中定义一个常量接口(或常量类),以囊括系统中所涉及的常量,从而简化代码,方便开发,在很多的开源项目中已采用了类似的方法,比如在Struts2中,org.apache.struts2.StrutsConstants就是一个常量类,它定义了Struts框架中与配置有关的常量,而org.apache.struts2.StrutsStatics则是一个常量接口,其中定义了OGNL访问的关键字。
1700440006
1700440007
关于常量接口(类)我们来看一个例子,首先定义一个常量类:
1700440008
1700440009
public class Constant{
1700440010
1700440011
//定义人类寿命极限
[
上一页 ]
[ :1.700439962e+09 ]
[
下一页 ]