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
导致子类代码膨胀
1700449125
1700449126
在我们的例子中子类的无参构造函数不能省略，原因是父类的无参构造函数抛出了IOException异常，子类的无参构造函数默认调用的是父类的构造函数，所以子类的无参构造也必须抛出IOException或其父类。
1700449127
1700449128
违背了里氏替换原则
1700449129
1700449130
里氏替换原则是说“父类能出现的地方子类就可以出现，而且将父类替换为子类也不会产生任何异常”，那我们回过头来看看Sub类是否可以替换Base类，比如我们的上层代码是这样写的：
1700449131
1700449132
public static void main（String[]args）{
1700449133
1700449134
try{
[
上一页 ]
[ :1.700449085e+09 ]
[
下一页 ]