1700449165
1700449166
//子类方法的异常类型必须是父类方法的子类型
1700449167
1700449168
@Override
1700449169
1700449170
public void method（）throws IOException{
1700449171
1700449172
}
1700449173
1700449174
}
1700449175
1700449176
子类的方法可以抛出多个异常，但都必须是被覆写方法的子类型，对我们的例子来说，Sub类的method方法抛出的异常必须是Exception的子类或Exception类，这是Java覆写的要求。构造函数之所以与此相反，是因为构造函数没有覆写的概念，只是构造函数间的引用调用而已，所以在构造函数中抛出受检异常会违背里氏替换原则，使我们的程序缺乏灵活性。
1700449177
1700449178
子类构造函数扩展受限
1700449179
1700449180
子类存在的原因就是期望实现并扩展父类的逻辑，但是父类构造函数抛出异常却会让子类构造函数的灵活性大大降低，例如我们期望这样的构造函数。
1700449181
1700449182
class Sub extends Base{
1700449183
1700449184
public Sub（）throws Exception{
1700449185
1700449186
try{
1700449187
1700449188
super（）；
1700449189
1700449190
}catch（IOException e）{
1700449191
1700449192
//异常处理后再抛出
1700449193
1700449194
throw e；
1700449195
1700449196
}finally{
1700449197
1700449198
//收尾处理
1700449199
1700449200
}
1700449201
1700449202
}
1700449203
1700449204
}
1700449205
1700449206
很不幸，这段代码编译通不过，原因是构造函数Sub中没有把super（）放在第一句话中，想把父类的异常重新包装后再抛出是不可行的（当然，这里有很多种“曲线”的实现手段，比如重新定义一个方法，然后父子类的构造函数都调用该方法，那么子类构造函数就可以自由处理异常了），这是Java语法限制。
1700449207
1700449208
将以上三种异常类型汇总起来，对于构造函数，错误只能抛出，这是程序人员无能为力的事情；非受检异常不要抛出，抛出了“对己对人”都是有害的；受检异常尽量不抛出，能用曲线的方式实现就用曲线方式实现，总之一句话：在构造函数中尽可能不出现异常。
1700449209
1700449210
注意 在构造函数中不要抛出异常，尽量曲线救国。
1700449211
1700449212
1700449213
1700449214
[
上一页 ]
[ :1.700449165e+09 ]
[
下一页 ]