Java异常处理机制:try-catch
try{
代码片段
}catch(XXXException e){
处理try代码片段中出现的xxxException
}catch(Exception e){
...
}
通常在最后一个catch中捕获Exception,防止中断
try的()中只能定义实现了Autocloseable接口的内容。否则会出现编译不通过的情况,最终编译器会将代码改为在finally中关闭这里定义的需要关闭的内容。
何时使用throw抛出一个异常
1.通常遇到以下两种情况时我们会抛出异常
1.1 当程序遇到一个满足语法但是不满足业务逻辑的运行情况时,可以主动实例化一个异常抛出给调用这个以告知这种情况不允许;
1.2 程序确实出现了一个异常,但是该异常不应当在当前代码段中被解决,可以对外继续抛出异常
当一个方法中使用throw抛出某个异常时,就要使用throws关键字在声明方法的同时声明该异常的抛出,以通知调这处理异常只有RuntimeException。在方法中泡壶时可以不在方法上声明该异常的抛出,除此之外的其他异常则是必须的,否则编译不通过。
当我们调用一个含有throws声明异常抛出的方法时就必须处理该异常,否则编译不通过。处理手段有两种: 1. 使用try-catch处理该异常 2. 在当前方法上继续对外抛出取决与业务需求的责任问题,视具体情况而定,不应当在main方法上使用throws声明异常的抛出。
子类在重写父类含有throws声明异常抛出的方法时对于throws的重写准则。
1. 允许抛出部分异常
2. 允许不再抛出任何异常
3. 允许抛出父类方法抛出异常的子类型异常
4. 不允许抛出其他异常
5. 不允许抛出父类方法抛出异常的父类型异常
RuntimeExcepotion
非检测异常,因为普通JVM操作引起的运行时异常随时可能发生,此类异常一般是由特定操作引发,但这些操作在java应用程序中会频繁出现。因此它们不受编译器检查与处理或声明规则的限制。
常见RuntimeException
IllegalArgumentException 传递不合法或者不正确的参数
NullPointerExcepiton 空引用
ArrayIndexOutOfBoundsException 使用的数组下标超出数组允许范围
ClassCastException 强制转换为不是实例的子类
NumberFormatException 应用程序视图将字符串转换成一种数值类型,但不能转为适当格式时,抛出该异常
Exception常用API
e.printStackTrace();
e.getMessage();
getCause();检查异常导致的原因
12.12.3把“被检查的异常”转换为“不检查的异常”
在编写自己使用的简单程序时,从main()中抛出异常很方便的,但这不是通用的方法。问题的实质是,当在一个普通方法里调用别的方法时,要考虑到“我不知道该这样处理这个异常,但是也不想把它‘吞’了,或者打印一些无用的信息”。JDK1.4的异常链提供了一种新的思路来解决这个问题。可以直接把“被检查的异常”包装进RuntimeExcepiton里面,就像这样:
try{
// ... to do something useful
}catch(IDontKnowWhatTODoWithThisCheckedException e){
throw new RuntimeException(e);
}
如果想把“被检查的异常”这种功能“屏蔽”掉的话,这看上去像是一个好办法。不用“吞下”异常,也不必把它放到方法的异常说明里,而异常链还能保证你不会丢失任何原始异常的信息。
这种技巧给了你一种选择,你可以不写try-catch字句和/或异常说明,直接忽略异常,让它自己沿着调用线往上“冒泡”。同时,还可以用getCause()捕获并处理特定的异常。
异常使用指南
应该在下列情况下使用异常
- 在恰当的级别处理问题(在知道该如果处理的情况下才捕获异常)
- 解决问题并且重新调用产生异常的方法
- 进行少许修补,然后绕过异常发生的地方继续执行
- 用别的数据进行计算,以代替方法预计会返回的值
- 把当前运行环境下能做的事情尽量做完,然后把相同的异常抛到更高层
- 把当前运行环境下能做的事情尽量做完,然后把不同的异常抛到更高层
- 终止程序
- 进行简化。(如果你的异常模式使问题变得太复杂,那用起来会非常痛苦也很烦人。)
- 让类库和程序安全。(这既是在为调试做短期投资,也是在为程序的健壮性做长期投资。)
|