编写高质量代码：改善Java程序的151个建议（6）

　　建议19：断言绝对不是鸡肋

　　在防御式编程中经常会用断言（Assertion）对参数和环境做出判断，避免程序因不当的输入或错误的环境而产生逻辑异常，断言在很多语言中都存在，C、C++、Python都有不同的断言表示形式。在Java中的断言使用的是assert关键字，其基本的用法如下：

assert<布尔表达式> assert<布尔表达式>:<错误信息>

　　在布尔表达式为假时，抛出AssertionError错误，并附带了错误信息。assert的语法较简单，有以下两个特性：

　　（1）assert默认是不启用的

　　我们知道断言是为调试程序服务的，目的是为了能够快速、方便地检查到程序异常，但Java在默认条件下是不启用的，要启用就需要在编译、运行时加上相关的关键字，这就不多说，有需要的话可以参考一下Java规范。

　　（2）assert抛出的异常AssertionError是继承自Error的

　　断言失败后，JVM会抛出一个AssertionError错误，它继承自Error，注意，这是一个错误，是不可恢复的，也就表示这是一个严重问题，开发者必须予以关注并解决之。

　　assert虽然是做断言的，但不能将其等价于if…else…这样的条件判断，它在以下两种情况不可使用：

　　（1）在对外公开的方法中

　　我们知道防御式编程最核心的一点就是：所有的外部因素（输入参数、环境变量、上下文）都是“邪恶”的，都存在着企图摧毁程序的罪恶本源，为了抵制它，我们要在程序中处处检验，满地设卡，不满足条件就不再执行后续程序，以保护主程序的正确性，处处设卡没问题，但就是不能用断言做输入校验，特别是公开方法。我们来看一个例子：

publicclassClient{ publicstaticvoidmain(String[]args){ StringUtils.encode(null); } } //字符串处理工具类 classStringUtils{ publicstaticStringencode(Stringstr){ assertstr!=null:”加密的字符串为null”; /*加密处理*/ } }

　　encode方法对输入参数做了不为空的假设，如果为空，则抛出AssertionError错误，但这段程序存在一个严重的问题，encode是一个public方法，这标志着是它对外公开的，任何一个类只要能够传递一个String类型的参数（遵守契约）就可以调用，但是Client类按照规范和契约调用enocde方法，却获得了一个AssertionError错误信息，是谁破坏了契约协定？—是encode方法自己。

　　（2）在执行逻辑代码的情况下

　　assert的支持是可选的，在开发时可以让它运行，但在生产系统中则不需要其运行了（以便提高性能），因此在assert的布尔表达式中不能执行逻辑代码，否则会因为环境不同而产生不同的逻辑，例如：

publicvoiddoSomething(Listlist,Objectelement){ assertlist.remove(element):”删除元素”+element+”失败”; /*业务处理*/ }

　　这段代码在assert启用的环境下，没有任何问题，但是一旦投入到生产环境，就不会启用断言了，而这个方法也就彻底完蛋了，list的删除动作永远都不会执行，所以也就永远不会报错或异常，因为根本就没有执行嘛！

　　以上两种情况下不能使用assert，那在什么情况下能够使用assert呢？一句话：按照正常执行逻辑不可能到达的代码区域可以放置assert。具体分为三种情况：

　　（1）在私有方法中放置assert作为输入参数的校验

　　在私有方法中可以放置assert校验输入参数，因为私有方法的使用者是作者自己，私有方法的调用者和被调用者之间是一种弱契约关系，或者说没有契约关系，其间的约束是依靠作者自己控制的，因此加上assert可以更好地预防自己犯错，或者无意的程序犯错。

　　（2）流程控制中不可能达到的区域

　　这类似于JUnit的fail方法，其标志性的意义就是：程序执行到这里就是错误的，例如：

publicvoiddoSomething(){ inti=7; while(i>7){ /*业务处理*/ } assertfalse:”到达这里就表示错误”; }

　　（3）建立程序探针

　　我们可能会在一段程序中定义两个变量，分别代表两个不同的业务含义，但是两者有固定的关系，例如var1=var2*2，那我们就可以在程序中到处设“桩”，断言这两者的关系，如果不满足即表明程序已经出现了异常，业务也就没有必要运行下去了。

　　建议20：不要只替换一个类

　　我们经常在系统中定义一个常量接口（或常量类），以囊括系统中所涉及的常量，从而简化代码，方便开发，在很多的开源项目中已采用了类似的方法，比如在Struts2中，org.apache.struts2.StrutsConstants就是一个常量类，它定义了Struts框架中与配置有关的常量，而org.apache.struts2.StrutsStatics则是一个常量接口，其中定义了OGNL访问的关键字。

　　关于常量接口（类）我们来看一个例子，首先定义一个常量类：

publicclassConstant{ //定义人类寿命极限 publicfinalstaticintMAX_AGE=150; }

　　这是一个非常简单的常量类，定义了人类的最大年龄，我们引用这个常量，代码如下：

publicclassClient{ publicstaticvoidmain(String[]args){ System.out.println(“人类寿命极限是：”+Constant.MAX_AGE); } }

　　运行的结果非常简单（结果省略）。目前的代码编写都是在“智能型”IDE工具中完成的，下面我们暂时回溯到原始时代，也就是回归到用记事本编写代码的年代，然后看看会发生什么奇妙事情（为什么要如此，稍后会给出答案）。

　　修改常量Constant类，人类的寿命增加了，最大能活到180岁，代码如下：

publicclassConstant{ //定义人类寿命极限 publicfinalstaticintMAX_AGE=180; }

　　然后重新编译：javac Constant，编译完成后执行：java Client，大家想看看输出的极限年龄是多少岁吗？

　　输出的结果是：“人类寿命极限是：150”，竟然没有改变为180，太奇怪了，这是为何？

　　原因是：对于final修饰的基本类型和String类型，编译器会认为它是稳定态（Immutable Status），所以在编译时就直接把值编译到字节码中了，避免了在运行期引用（Run-time Reference），以提高代码的执行效率。针对我们的例子来说，Client类在编译时，字节码中就写上了“150”这个常量，而不是一个地址引用，因此无论你后续怎么修改常量类，只要不重新编译Client类，输出还是照旧。

　　而对于final修饰的类（即非基本类型），编译器认为它是不稳定态（Mutable Status），在编译时建立的则是引用关系（该类型也叫做Soft Final），如果Client类引入的常量是一个类或实例，即使不重新编译也会输出最新值。

　　千万不可小看了这点知识，细坑也能绊倒大象，比如在一个Web项目中，开发人员修改一个final类型的值（基本类型），考虑到重新发布风险较大，或者是时间较长，或者是审批流程过于繁琐，反正是为了偷懒，于是直接采用替换class类文件的方式发布。替换完毕后应用服务器自动重启，然后简单测试一下（比如本类引用final类型的常量），一切OK。可运行几天后发现业务数据对不上，有的类（引用关系的类）使用了旧值，有的类（继承关系的类）使用的是新值，而且毫无头绪，让人一筹莫展，其实问题的根源就在于此。

　　恩，还有个小问题没有说明，我们的例子为什么不在IDE工具（比如Eclipse）中运行呢？那是因为在IDE中不能重现该问题，若修改了Constant类，IDE工具会自动编译所有的引用类，“智能”化屏蔽了该问题，但潜在的风险其实仍然存在。

　　注意：发布应用系统时禁止使用类文件替换方式，整体WAR包发布才是万全之策。

相关文章：

你感兴趣的文章：

标签云：