1700449053
1700449054
}
1700449055
1700449056
}
1700449057
1700449058
//看限制级的电影
1700449059
1700449060
public void seeMovie（）{
1700449061
1700449062
System.out.println（“看限制级电影”）；
1700449063
1700449064
}
1700449065
1700449066
}
1700449067
1700449068
这段代码的意图很明显，年龄不满18岁的用户根本不会生成一个Person实例对象，没有对象，类行为seeMovie方法就不可执行，想法很好，但这会导致不可预测的结果，比如我们这样引用Person类。
1700449069
1700449070
public static void main（String[]args）{
1700449071
1700449072
Person p=new Person（17）；
1700449073
1700449074
p.seeMovie（）；
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{
[
上一页 ]
[ :1.700449053e+09 ]
[
下一页 ]