1700449075
1700449076
/*其他的逻辑处理*/
1700449077
1700449078
}
1700449079
1700449080
很显然，p对象不能建立，因为是一个RuntimeException异常，开发人员可以捕捉也可以不捕捉，代码看上去逻辑很正确，没有任何瑕疵，但是事实上，这段程序会抛出异常，无法执行。这段代码给了我们两个警示：
1700449081
1700449082
加重了上层代码编写者的负担
1700449083
1700449084
捕捉这个RuntimeException异常吧，那谁来告诉我有这个异常呢？只有通过文档来约束了，一旦Person类的构造函数经过重构后再抛出其他非受检异常，那main方法不用修改也是可以通过测试的，但是这里就可能会产生隐藏的缺陷，而且还是很难重现的缺陷。
1700449085
1700449086
不捕捉这个RuntimeException异常，这是我们通常的想法，既然已经写成了非受检异常，main方法的编码者完全可以不处理这个异常嘛，大不了不执行Person的方法！这是非常危险的，一旦产生异常，整个线程都不再继续执行，或者连接没有关闭，或者数据没有写入数据库，或者产生内存异常，这些都是会对整个系统产生影响。
1700449087
1700449088
后续代码不会执行
1700449089
1700449090
main方法的实现者原本只是想把p对象的建立作为其代码逻辑的一部分，执行完seeMovie方法后还需要完成其他逻辑，但是因为没有对非受检异常进行捕捉，异常最终会抛出到JVM中，这会导致整个线程执行结束后，后面所有的代码都不会继续执行了，这就对业务逻辑产生了致命的影响。
1700449091
1700449092
（3）构造函数尽可能不要抛出受检异常
1700449093
1700449094
我们来看下面的例子，代码如下：
1700449095
1700449096
//父类
1700449097
1700449098
class Base{
1700449099
1700449100
//父类抛出IOException
1700449101
1700449102
public Base（）throws IOException{
1700449103
1700449104
throw new IOException（）；
1700449105
1700449106
}
1700449107
1700449108
}
1700449109
1700449110
//子类
1700449111
1700449112
class Sub extends Base{
1700449113
1700449114
//子类抛出Exception异常
1700449115
1700449116
public Sub（）throws Exception{
1700449117
1700449118
}
1700449119
1700449120
}
1700449121
1700449122
就这么一段简单的代码，展示了在构造函数中抛出受检异常的三个不利方面：
1700449123
1700449124
导致子类代码膨胀
[
上一页 ]
[ :1.700449075e+09 ]
[
下一页 ]