首页 » 编写高质量代码:改善Java程序的151个建议 » 编写高质量代码:改善Java程序的151个建议全文在线阅读

《编写高质量代码:改善Java程序的151个建议》建议114:不要在构造函数中抛出异常

关灯直达底部

Java的异常机制有三种:

Error类及其子类表示的是错误,它是不需要程序员处理也不能处理的异常,比如VirtualMachineError虚拟机错误,ThreadDeath线程僵死等。

RuntimeException类及其子类表示的是非受检异常,是系统可能会抛出的异常,程序员可以去处理,也可以不处理,最经典就是NullPointerException空指针异常和IndexOutOfBoundsException越界异常。

Exception类及其子类(不包含非受检异常)表示的是受检异常,这是程序员必须处理的异常,不处理则程序不能通过编译,比如IOException表示I/O异常,SQLException表示数据库访问异常。

我们知道,一个对象的创建要经过内存分配、静态代码初始化、构造函数执行等过程,对象生成的关键步骤是构造函数,那是不是也允许在构造函数中抛出异常呢?从Java语法上来说,完全可以在构造函数中抛出异常,三类异常都可以,但是从系统设计和开发的角度来分析,则尽量不要在构造函数中抛出异常,我们以三种不同类型的异常来说明之。

(1)构造函数抛出错误是程序员无法处理的

在构造函数执行时,若发生了VirtualMachineError虚拟机错误,那就没招了,只能抛出,程序员不能预知此类错误的发生,也就不能捕捉处理。

(2)构造函数不应该抛出非受检异常我们来看这样一个例子,代码如下:


class Person{

public Person(int_age){

//不满18岁的用户对象不能建立

if(_age<18){

throw new RuntimeException(/"年龄必须大于18岁。/");

}

}

//看限制级的电影

public void seeMovie(){

System.out.println(/"看限制级电影/");

}

}


这段代码的意图很明显,年龄不满18岁的用户根本不会生成一个Person实例对象,没有对象,类行为seeMovie方法就不可执行,想法很好,但这会导致不可预测的结果,比如我们这样引用Person类。


public static void main(Stringargs){

Person p=new Person(17);

p.seeMovie();

/*其他的逻辑处理*/

}


很显然,p对象不能建立,因为是一个RuntimeException异常,开发人员可以捕捉也可以不捕捉,代码看上去逻辑很正确,没有任何瑕疵,但是事实上,这段程序会抛出异常,无法执行。这段代码给了我们两个警示:

加重了上层代码编写者的负担

捕捉这个RuntimeException异常吧,那谁来告诉我有这个异常呢?只有通过文档来约束了,一旦Person类的构造函数经过重构后再抛出其他非受检异常,那main方法不用修改也是可以通过测试的,但是这里就可能会产生隐藏的缺陷,而且还是很难重现的缺陷。

不捕捉这个RuntimeException异常,这是我们通常的想法,既然已经写成了非受检异常,main方法的编码者完全可以不处理这个异常嘛,大不了不执行Person的方法!这是非常危险的,一旦产生异常,整个线程都不再继续执行,或者连接没有关闭,或者数据没有写入数据库,或者产生内存异常,这些都是会对整个系统产生影响。

后续代码不会执行

main方法的实现者原本只是想把p对象的建立作为其代码逻辑的一部分,执行完seeMovie方法后还需要完成其他逻辑,但是因为没有对非受检异常进行捕捉,异常最终会抛出到JVM中,这会导致整个线程执行结束后,后面所有的代码都不会继续执行了,这就对业务逻辑产生了致命的影响。

(3)构造函数尽可能不要抛出受检异常

我们来看下面的例子,代码如下:


//父类

class Base{

//父类抛出IOException

public Base()throws IOException{

throw new IOException();

}

}

//子类

class Sub extends Base{

//子类抛出Exception异常

public Sub()throws Exception{

}

}


就这么一段简单的代码,展示了在构造函数中抛出受检异常的三个不利方面:

导致子类代码膨胀

在我们的例子中子类的无参构造函数不能省略,原因是父类的无参构造函数抛出了IOException异常,子类的无参构造函数默认调用的是父类的构造函数,所以子类的无参构造也必须抛出IOException或其父类。

违背了里氏替换原则

里氏替换原则是说“父类能出现的地方子类就可以出现,而且将父类替换为子类也不会产生任何异常”,那我们回过头来看看Sub类是否可以替换Base类,比如我们的上层代码是这样写的:


public static void main(Stringargs){

try{

Base base=new Base();

}catch(IOException e){

//异常处理

}

}


然后,我们期望把new Base()替换成new Sub(),而且代码能够正常编译和运行。非常可惜,编译通不过,原因是Sub的构造函数抛出了Exception异常,它比父类的构造函数抛出的异常范围要宽,必须增加新的catch块才能解决。

可能有读者要问了,为什么Java的构造函数允许子类的构造函数抛出更广泛的异常类呢?这正好与类方法的异常机制相反,类方法的异常是这样要求的:


//父类

class Base{

//父类方法抛出Exception

public void method()throws Exception{

}

}

//子类

class Sub extends Base{

//子类方法的异常类型必须是父类方法的子类型

@Override

public void method()throws IOException{

}

}


子类的方法可以抛出多个异常,但都必须是被覆写方法的子类型,对我们的例子来说,Sub类的method方法抛出的异常必须是Exception的子类或Exception类,这是Java覆写的要求。构造函数之所以与此相反,是因为构造函数没有覆写的概念,只是构造函数间的引用调用而已,所以在构造函数中抛出受检异常会违背里氏替换原则,使我们的程序缺乏灵活性。

子类构造函数扩展受限

子类存在的原因就是期望实现并扩展父类的逻辑,但是父类构造函数抛出异常却会让子类构造函数的灵活性大大降低,例如我们期望这样的构造函数。


class Sub extends Base{

public Sub()throws Exception{

try{

super();

}catch(IOException e){

//异常处理后再抛出

throw e;

}finally{

//收尾处理

}

}

}


很不幸,这段代码编译通不过,原因是构造函数Sub中没有把super()放在第一句话中,想把父类的异常重新包装后再抛出是不可行的(当然,这里有很多种“曲线”的实现手段,比如重新定义一个方法,然后父子类的构造函数都调用该方法,那么子类构造函数就可以自由处理异常了),这是Java语法限制。

将以上三种异常类型汇总起来,对于构造函数,错误只能抛出,这是程序人员无能为力的事情;非受检异常不要抛出,抛出了“对己对人”都是有害的;受检异常尽量不抛出,能用曲线的方式实现就用曲线方式实现,总之一句话:在构造函数中尽可能不出现异常。

注意 在构造函数中不要抛出异常,尽量曲线救国。