(一)Java的异常层次结构
要想明白Java中checked Exception和unchecked Exception的区别,我们首先来看一下Java的异常层次结构。
这是一个简化的Java异常层次结构示意图,需要注意的是所有的类都是从Throwable继承而来,下一层则分为两个结构,Error和Exception。其中Error类层次描述了Java运行时系统的内部错误和资源耗尽错误,这种错误除了简单的报告给用户,并尽力阻止程序安全终止之外,一般也米有别的解决办法了。
最常用的五种RuntimeException:
ArithmeticException | int a=0; |
ClassCastException: | Object x = new Integer(0); |
IndexOutOfBoundsException | int [] numbers = { 1, 2, 3 }; |
IllegalArgumentException | int a = Interger.parseInt("test"); |
NullPointerExceptionextends | 继承自 RuntimeException,所以它是个 unchecked exception。 |
(二)unchecked异常和checked异常的区别
Java 定义了两种异常(C#只有unchecked异常):
- Checked exception: 继承自 Exception 类是 checked exception。代码需要处理 API 抛出的 checked exception,要么用 catch 语句,要么直接用 throws 语句抛出去。
- Unchecked exception: 也称 RuntimeException,它也是继承自 Exception。但所有 RuntimeException 的子类都有个特点,就是代码不需要处理它们的异常也能通过编译,所以它们称作 unchecked exception。RuntimeException(运行时异常)不需要try...catch...或throws 机制去处理的异常。
将派生于Error或者RuntimeException的异常称为unchecked异常,所有其他的异常成为checked异常。尽管,这个定义十分简单,但是RuntimeException却是一个非常让人容易混淆的观念,似乎我们所有的异常都是在程序运行的过程中。我《Effective Java》中关于Ru ntimeException异常的阐述也不是那么尽如人意,
Use checked exceptions for recoverable conditions and runtime exceptions for programming errors (Item 58 in 2nd edition)
不过从这句话中我们可以简单引申一下,也就是说,如果出现了RuntimeException,就一定是程序员自身的问题。比如说,数组下标越界和访问空指针异常等等,只要你稍加留心这些异常都是在编码阶段可以避免的异常。如果你还是觉得这两个概念不好区分,那么“最暴力“的方法就是将常见的RuntimeException背下来,这样就可以省去很多判断的时间。
(三)为什么要对unchecked异常和checked异常进行区分?
原因其实很简单,编译器将检查你是否为所有的已检查异常提供了异常处理机制,比如说我们使用Class.forName()来查找给定的字符串的class对象的时候,如果没有为这个方法提供异常处理,编译是无法通过的。
(四)我们应该对哪些异常进行声明?
我们前面说,RuntimeException是在programing过程中可以避免的错误,那是不是我们就不需要抛出这些异常呢?原则上来说,是这样的,但是Java规范中并没有对此进行限制,只是看上去你抛出一个数组越界的异常并没有多少实际意义,相反还会对性能造成一定的损失。那么我们应该如何来设计抛出异常呢?我们要记住以下两种情况是必声明throws异常的:
调用一个checked异常的方法,例如IOException,至于原因我们前面已经讨论过了,如果抛出所有的checked异常时无法通过编译的。
程序运行过程中发现错误,利用throw语句抛出一个异常。
对于unchecked异常,无非主要是两种情况要么是可以避免的(Runtime Exception),要么是不可控制的。这些也是需要声明异常的。
继承 | 处理 | 区别 | 建议 | |
---|---|---|---|---|
checked异常 | java.lang.Exception | 必须显式地捕获或者传递,不处理编译不能通过 | ··Check异常的抛出作为方法接口的一部分,这使得添加或移除早期版本中方法的异常难以实现。 ··沿调用栈向上传播的Checked异常破坏了顶层的方法,因为这些方法必须声明抛出所有它们调用的方法抛出的异常。 | 遇到可恢复的错误时采用 |
unchecked异常 | java.lang.RuntimeException | 不必捕获或抛,编译可以通过 | ··
| 遇到不可恢复的异常 |