把好方法参数的大门

做编程工作这几年来，见识了不少烂代码，最常见的就是像下面那样的：

public void execute(Args args){

//方法体内对args没有作任何检查，直接使用执行。

}

所有的参数都从Args对象中取，多的时候大概有十几个参数，而在方法体内，直接使用参数，对参数没有作任何检查，大家可以想象一下调用这样的方法有多痛苦，经常执行到中途报一个错误，修改对参数后又抛出另一个异常，查了很久发现是另一个参数传错了，我说你不仅偷懒不写注释，连最基本的参数有效性检查都不做，这种方法写出来简直是对使用者的慢性谋杀啊。

一个方法该怎么写，看下基本类的源码就知道了。如String类的方法：

/**
     * @param      index   the index of the <code>char</code> value.
     * @return     the <code>char</code> value at the specified index of this string.
     *             The first <code>char</code> value is at index <code>0</code>.
     * @exception  IndexOutOfBoundsException  if the <code>index</code>
     *             argument is negative or not less than the length of this
     *             string.
     */
public char charAt(int index) {
 if ((index < 0) || (index >= value.length)) {
 throw new StringIndexOutOfBoundsException(index);
   }
 return value[index];
}

虽然有时候一些不懂编程的人对程序员的时间压得比较紧，我们没有足够时间去写这么完整的注释，但是在方法执行前对参数进行检查一般是必须的

if ((index < 0) || (index >= value.length)) {

throw new StringIndexOutOfBoundsException(index);

}

不做检查有什么后果：

1、有可能代码执行到中途报出一个令人困惑的bug，而这个bug通过参数有效性检查是很容易被排查解决的。

2、方法可以正常返回，返回值却是错误的

3、最糟糕的是，方法返回值正确，其中的一些对象状态却被侵入，这增加程序运行的不确定性，并在未来以一个难以排查的bug的形式表现出来。

对于公共方法，需要添加 @throws，@exception 这样的标记，对异常进行文档化，对于私有方法，由于你可以控制方法被调用的环境，你应该确保只有正确的参数被传入，可以使用断言assert。

private static void group(int[] a) {
 assert a != null;
 // Do the computation
}

断言是开发期间使用的，让程序在运行期间进行自检的代码，建议用来处理绝不应该发生的情况，如果检查失败，他会报AssertionError，在开发期间，你开启断言功能，排查相互矛盾的假定，例外情况和错误的数据，在上线时，关闭断言功能，以免降低系统性能。(java中，断言可以通过-enableassertions标记开启)。