密级:内部公开
{
//... ... }
finally {
try {
out.close(); }
catch (IOException ioe) {
//... ...
} try {
in.close(); }
catch (IOException ioe) {
//... ... }
}
规则2 系统非正常运行产生的异常捕获后，如果不对该异常进行处理，则应该记录日志。 (1.42+) 说明：此规则指通常的系统非正常运行产生的异常，不包括一些基于异常的设计。若有特殊原因必须用注释加以说明。 示例： try {
//.... ... }
catch (IOException ioe) {
logger.error(ioe); }
规则3 自己抛出的异常必须要填写详细的描述信息。(1.42+)
说明：便于问题定位。 示例：
throw new IOException(\
规则4 运行时异常使用RuntimeException的子类来表示，不用在可能抛出异常的方法声明上加
throws子句。非运行期异常是从Exception继承而来的，必须在方法声明上加throws子句。(1.42+)
说明：
非运行期异常是由外界运行环境决定异常抛出条件的异常，例如文件操作，可能受权限、磁盘空间大小的影响而失败，这种异常是程序本身无法避免的，需要调用者明确考虑该异常出现时该如
Page 11 , Total 19
密级:内部公开
何处理方法，因此非运行期异常必须有throws子句标出，不标出或者调用者不捕获该类型异常都会导致编译失败，从而防止程序员本身疏忽。
运行期异常是程序在运行过程中本身考虑不周导致的异常，例如传入错误的参数等。抛出运行期异常的目的是防止异常扩散，导致定位困难。因此在做异常体系设计时要根据错误的性质合理选择自定义异常的继承关系。
还有一种异常是Error 继承而来的，这种异常由虚拟机自己维护，表示发生了致命错误，程序无法继续运行例如内存不足。我们自己的程序不应该捕获这种异常，并且也不应该创建该种类型的异常。
规则5 在程序中使用异常处理还是使用错误返回码处理，根据是否有利于程序结构来确定，并
且异常和错误码不应该混合使用，推荐使用异常。(1.42+)
说明：
一个系统或者模块应该统一规划异常类型和返回码的含义。 但是不能用异常来做一般流程处理的方式，不要过多地使用异常，异常的处理效率比条件分支低，而且异常的跳转流程难以预测。
注意：Java 5.0 程序内部的错误码可以使用枚举来表示。
规则6 注意运算符的优先级，并用括号明确表达式的操作顺序，避免使用默认优先级。(1.42+) 说明：防止阅读程序时产生误解，防止因默认的优先级与设计思想不符而导致程序出错。 示例：
下列语句中的表达式
word = (high << 8) | low (1) if ((a | b) && (a & c)) (2) if ((a | b) < (c & d)) (3) 如果书写为
high << 8 | low a | b && a & c a | b < c & d
（1）（2）虽然不会出错，但语句不易理解；（3）造成了判断条件出错。
规则7 避免使用不易理解的数字，用有意义的标识来替代。涉及物理状态或者含有物理意义的
常量，不应直接使用数字，必须用有意义的静态变量或者枚举来代替。使用异常来表示方法执行错误，而不是使用C++的错误返回码方式。(1.42+)
示例：如下的程序可读性差。 if (state == 0) {
state = 1;
... // program code }
应改为如下形式：
private final static int TRUNK_IDLE = 0; private final static int TRUNK_BUSY = 1;
private final static int TRUNK_UNKNOWN = -1;
if (state == TRUNK_IDLE)
Page 12 , Total 19
密级:内部公开
{
state = TRUNK_BUSY; ... // program code }
注意：Java 5.0 下建议使用枚举来表示。
异常：
public void function() { ...
throw new RuntimeException(“。。。”); }
规则8 数组声明的时候使用 int[] index ，而不要使用 int index[] 。(1.42+)
说明：使用int index[] 格式使程序的可读性较差，int [] index 表示声明了一个int数组(int [])叫做index 示例：
如下程序可读性差：
public int getIndex()[] {
.... }
如下程序可读性好：
public int[] getIndex() {
.... }
规则9 不要使用 System.out 与 System.err 进行控制台打印，应该使用工具类(如：日志工具)
进行统一记录或者打印。(1.42+)
说明：代码发布的时候可以统一关闭控制台打印，代码调试的时候又可以打开控制台打印，方便调试。
规则10 用调测开关来切换软件的DEBUG版和正式版，而不要同时存在正式版本和DEBUG版本
的不同源文件，以减少维护的难度。 (1.42+)
规则11 集合必须指定模板类型(5.0+) 说明：方便程序阅读，除去强制转换代码 示例：
Map
规则12 一个文件不要定义两个类(并非指内部类)。(1.42+) 说明：方便程序的阅读与代码的维护
Page 13 , Total 19
密级:内部公开
规则13 所有的数据类必须覆写toString()、hashCode()、equals() 方法，toString()方法返回该
类有意义的内容。(1.42+)
说明：方便数据类的比较，父类如果实现了比较合理的toString() ，子类可以继承不必再重写。 hashCode与equals可以使用eclipse自动生成。 示例：
public TopoNode {
private String nodeName;
public String toString() {
return \ } }
规则14 判断语句不要使用”* == true”来判断为真 说明：方便阅读，减少没有必要的计算 以下错误：
if (ok == true) { }
以下正确： if (ok) { }
规则15 不要写没有必要的向上强制转型。(1.42+)
说明：没必要写的向上强制转型会浪费性能，增加代码阅读难度 示例： 以下错误：
FileInputStream fis = new FileInputStream(f); InputStream is = (InputStream)fis;
…… ……
1.4.2 建议
建议1 记录异常不要保存exception.getMessage()，而要记录exception.toString()，一般可通过日
志工具记录完整的异常堆栈信息。(1.42+)
Page 14 , Total 19
密级:内部公开
说明：NullPointException抛出时常常描述为空，这样往往看不出是出了什么错。 示例： try
{
... }
catch (FileNotFoundException e) {
logger.error(e); }
建议2 一个方法不应抛出太多类型的异常。(1.42+)
说明： 如果程序中需要分类处理，则将异常根据分类组织成继承关系。如果确实有很多异常类型首先考虑用异常描述来区别，throws/exception子句标明的异常最好不要超过三个。
建议3 异常捕获尽量不要直接 catch (Exception ex)，应该把异常细分处理。(1.42+) 说明：可以设计更合理异常处理分支
建议4 如果多段代码重复做同一件事情，那么在方法的划分上可能存在问题。(1.42+) 说明：若此段代码各语句之间有实质性关联并且是完成同一件功能的，那么可考虑把此段代码构造成一个新的方法。
建议5 集合中的数据如果不使用了应该及时释放，尤其是可重复使用的集合。(1.42+) 说明：由于集合保存了对象的引用，虚拟机的垃圾收集器就不会回收。
建议6 源程序中关系较为紧密的代码应尽可能相邻。(1.42+) 说明：便于程序阅读和查找。
示例：矩形的长与宽关系较密切，放在一起。 rect.length = 10; rect.width = 5;
建议7 不要使用难懂的技巧性很高的语句，除非很有必要时。(1.42+)
说明：高技巧语句不等于高效率的程序，实际上程序的效率关键在于设计与算法。
建议8 明确方法功能，精确（而不是近似）地实现方法设计。一个函数仅完成一件功能，即使
简单功能也编写方法实现。 (1.42+)
说明：虽然为仅用一两行就可完成的功能去编方法好象没有必要，但用方法可使功能明确化，增加程序可读性，亦可方便维护、测试。
建议9 应明确规定对接口方法参数的合法性检查应由方法的调用者负责还是由接口方法本身负
责，缺省是由方法调用者负责。(1.42+)
说明：对于模块间接口方法的参数的合法性检查这一问题，往往有两个极端现象，即：要么是调用者和被调用者对参数均不作合法性检查，结果就遗漏了合法性检查这一必要的处理过程，造成问题隐患；要么就是调用者和被调用者均对参数进行合法性检查，这种情况虽不会造成问题，但
Page 15 , Total 19