4.2 建议

建议1 记录异常不要保存exception.getMessage()，而要记录exception.toString()，一般可通过日志工具记录完整的异常堆栈信息。

说明：NullPointException抛出时常常描述为空，这样往往看不出是出了什么错。

示例：

try {
    ...
} catch (FileNotFoundException e) {
    logger.error(e);
}

建议2 一个方法不应抛出太多类型的异常。

说明： 如果程序中需要分类处理，则将异常根据分类组织成继承关系。如果确实有很多异常类型首先考虑用异常描述来区别，throws/exception子句标明的异常最好不要超过三个。

建议3 异常捕获尽量不要直接catch (Exception ex)，应该把异常细分处理。

说明：可以设计更合理异常处理分支。

建议4 如果多段代码重复做同一件事情，那么在方法的划分上可能存在问题。

说明：若此段代码各语句之间有实质性关联并且是完成同一件功能的，那么可考虑把此段代码构造成一个新的方法。

建议5 集合中的数据如果不使用了应该及时释放，尤其是可重复使用的集合。

说明：由于集合保存了对象的引用，虚拟机的垃圾收集器就不会回收。

建议6 源程序中关系较为紧密的代码应尽可能相邻。

说明：便于程序阅读和查找。

示例：矩形的长与宽关系较密切，放在一起。

rect.length = 10;
rect.width = 5;

建议7 不要使用难懂的技巧性很高的语句，除非很有必要时。

说明：高技巧语句不等于高效率的程序，实际上程序的效率关键在于设计与算法。

建议8 明确方法功能，精确（而不是近似）地实现方法设计。一个函数仅完成一件功能，即使简单功能也编写方法实现。

说明：虽然为仅用一两行就可完成的功能去编方法好象没有必要，但用方法可使功能明确化，增加程序可读性，亦可方便维护、测试。

建议9 应明确规定对接口方法参数的合法性检查应由方法的调用者负责还是由接口方法本身负责，缺省是由方法调用者负责。

说明：对于模块间接口方法的参数的合法性检查这一问题，往往有两个极端现象，即：要么是调用者和被调用者对参数均不作合法性检查，结果就遗漏了合法性检查这一必要的处理过程，造成问题隐患；要么就是调用者和被调用者均对参数进行合法性检查，这种情况虽不会造成问题，但产生了冗余代码，降低了效率。

建议10 尽量使用Java 5.0 For-Each循环写法。

说明：代码更加简洁。

示例：

ArrayList<String> list = new ArrayList<String>();
list.add...
for(String str:list) {
    System.out.println(str);
}

建议11 使用Java 5.0枚举来替代以前用数字与字符串的同等目的的操作。

说明：Java 5.0以前没有枚举，大家都用数字或者字符串做枚举同样功能的事情。

示例：

public enum EnumDemo {
    ERROR,INFO,DEBUG
}

public void test() {
    EnumDemo t = EnumDemo.DEBUG;
    if (t == EnumDemo.ERROR) {
        ...
    }
}

建议12 interface中定义的常量不要写public、static、final的修饰词，方法不要写public修饰词。

说明：更加简洁。

示例：

public interface InterfaceT {
    String alphaBeta = "abc";
    void doStart();
}

建议13 新起一个线程，都要使用Thread.setName("…")设置线程名。

说明：性能测试时可对线程状态进行监控，异常时也可以知道异常发生在哪个线程中。