（java）异常处理原理和原则

原文链接：/article/4872944.html

Todd.log - a place to keep my thoughts
on programming

异常处理原理和原则

异常机制是现代主流语言的标配，但是异常处理问题虽然已经被讨论很多，也有很多经典书籍的论述，却一直都充满争议。很多人都觉得异常处理很难拿捏，同时也难以理解一些语言或库的异常处理设计。我使用Java近10年，但直到最近我才感觉完全理清了对于异常处理的种种疑惑，下面就介绍一下我对Java异常处理原理和原则的一些认识，欢迎交流探讨！

Exception和Error的区别

谈异常处理的第一个问题是：什么是异常？什么又不是异常？这个问题看似简单，其实很多人都没有分辨清楚，尤其是人们经常混用异常(Exception)、错误(Error)、失败(Failure)、缺陷(Bug)这些接近又有区别的词。
这里最需要对比区分的是Failure/Exception和Bug/Error。用例子来说，你尝试打开一个文件失败了，触发了一个

IOException

，这是一种运行时遇到的操作失败，它并不代表你的程序本身有问题。但是，Bug就不一样了，假设你有一个

sort

函数对数组进行排序，如果发现调用

sort

之后居然还有乱序情况，导致整个系统行为出错最后crash，那么这就不是异常而是错误，唯一的解决办法是修改程序解决Bug。所以，在Java中我们可以这样区分，异常(Exception)是一种非程序原因的操作失败(Failure)，而错误(Error)则意味着程序有缺陷(Bug)。注意：其他语言术语可能不同，重要的是能从概念上区分它们。
Java的类继承体系非常清楚地区分了Exception和Error。

java.lang.Object
java.lang.Throwable
java.lang.Error
java.lang.Exception

Exception下面是我们常见的各种异常类，Error下面最著名的就是

AssertionError

，它可以通过

throw
new AssertionError(...)

显式抛出，也可以通过

assert

操作符产生。Java文档中明确说到：

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.
就是说一般情况下不应该尝试用

catch(Throwable)

或者

catch(Error)

去捕获Error，因为抛出这个Error就是希望整个程序马上停下来。可能有人会疑惑：“如果不捕获Error，程序crash了后果很严重啊”？这个就要靠自己结合具体情况去判断了，让程序带着已经发作的Bug跑还是立刻停下来，到底哪个后果更严重？有时是前者，有时是后者。

声明异常和未声明异常的区别

Java可以在方法签名上显式地声明可能抛出的异常，但也允许抛出某些未声明的异常。那么，二者有何区别呢？我们自己在设计一个方法时如何决定是否在方法上声明某个异常呢？本质上讲，在方法签名上声明的异常属于方法接口的一部分，它和方法的返回值处于同一抽象层次，不随具体实现的变化而改变。比如，Integer类用于解析一个字符串到Integer型整数的valueOf方法：

public static Integer valueOf(String s) throws NumberFormatException

它声明抛出的

NumberFormatException

属于这个方法接口层面的一种失败情况，不管内部实现采用什么解析方法，都必然存在输入字符串不是合法整数这种情况，所以这时把这个异常声明出来就非常合理。相反，下面这个从帐户a向帐户b转账的

transfer

方法：

public boolean transfer(Account a, Account b, Money money) throws SQLException

它抛出

SQLException

就不对了，因为

SQLException

不属于这个

transfer

接口层面的概念，而属于具体实现，很有可能未来某个实现不用SQL了那么这个异常也就不存在了。这种情况下，就应该捕获

SQLException

，然后抛出自定义异常

TransferException

，其中

TransferException

可以定义几种和业务相关的典型错误情况，比如金额不足，帐户失效，通信故障，同时它还可以引用

SQLException

作为触发原因(Cause)。

public boolean transfer(Account a, Account b, Money money) throws TransferException {
try {
...
executeSQL(...);
} catch (SQLException e) {
throw new TransferException("...", e);
}
}

什么情况下方法应该抛出未声明的异常？

前面谈到在编写一个方法时，声明异常属于接口的一部分，不随着具体实现而改变，但是我们知道Java允许抛出未声明的

RuntimeException

，那么什么情况下会这样做呢？比如，下面的例子中方法

f

声明了

FException

，但是它的实现中可能抛出

RuntimeException

，这是什么意思呢？

void f() throws FException {
if (...) {
throw new RuntimeException("...");
}
}

根据上面提到的原理，未声明异常是和实现相关的，有可能随着不同实现而出现或消失，同时它又对应不到FException。比如，

f

方法依赖于对象

a

，结果在运行时

a

居然是

null

，导致本方法无法完成相应功能，这就可以成为一种未声明的

RuntimeException

了（当然，更常见的是直接调用

a

的方法，然后触发

NullPointerException

）。
其实，很多情况下抛出未声明的

RuntimeException

的语义和Error非常接近，只是没有Error那么强烈，方法的使用者可以根据情况来处理，不是一定要停止整个程序。我们最常见的

RuntimeException

可能要算

NullPointerException

了，通常都是程序Bug引起的，如果是C/C++就已经crash了，Java给了你一个选择如何处理的机会。
所以，抛出未声明异常表示遇到了和具体实现相关的运行时错误，它不是在设计时就考虑到的方法接口的一部分，所以又被称为是不可恢复的异常。有些Java程序员为了简便不声明异常而直接抛出RuntimeException的做法从设计上是不可取的。

如何捕获和处理其他方法抛出的异常？

下面例子中方法

g

声明了

GException

，方法

f

声明了

FException

，而

f

在调用

g

的时候不管三七二十一通过

catch
(Exception e)

捕获了所有的异常。

void g() throws GException
void f() throws FException {
try {
g();
} catch (Exception e) {
...
}
....
}

这种做法是很多人的习惯性写法，它的问题在哪里呢？问题就在于

g

明明已经告诉你除了

GException

外，如果抛出未声明的RuntimeException就表示遇到了错误，很可能是程序有Bug，这时

f

还不顾一切继续带着Bug跑。所以，除非有特殊理由，对具体情况做了分析判断，一般不捕获未声明异常，让它直接抛出就行。下面两种方式可以根据情况选择其一，不推荐为了省事直接捕获所有异常。

void g() throws GException
void f() throws FException {
try {
g();
} catch (GException e) {
...
}
....
}

或者（前提是

GException

继承自

RuntimeException

)

void g() throws GException
void f() throws FException {
g();
....
}

但是，很遗憾有一种很典型的情况是

g()

是不受自己控制的代码，它虽然只声明了抛出

GException

，实际上它在实现的时候抛出了本来应该声明出来的异常。如果遇到这种情况最好的做法是应该告诉

g()

的作者修改程序声明出这些异常，如果实在不行也只能全部捕获了。但是，对于自己写的程序来讲，一定要严格区别声明异常和未声明异常的处理，这样做的目的是理清Exception和Bug的界限。

自定义异常应继承Exception还是RuntimeException?

Java中区分Checked Exception和Unchecked Exception，前者继承于

Exception

，后者继承于

RuntimeException

。Unchecked
Exception和Runtime Exception在Java中常常是指同一个意思。

public boolean createNewFile() throws IOException

上面的

IOException

就是一个著名的Checked
Exception。Java编译器对Checked Exception的约束包括两方面：对于方法编写者来讲，Checked Exception必须在方法签名上声明；对于方法调用者来讲，调用抛出Checked Exception的方法必须用try-catch捕获异常或者继续声明抛出。相反，Unchecked Exception则不需要显式声明，也不强制捕获。
Checked Exception的用意在于明确地提醒调用者去处理它，防止遗漏。但是Checked Exception同时也给调用者带来了负担，通常会导致层层的try-catch，降低代码的可读性，前面例子中的

Integer.valueOf

方法虽然声明了

NumberFormatException

，但是它是一个

RuntimeException

，所以使用者不是必须用try-catch去捕获它。
实际上，对于自己编写的异常类来讲，推荐默认的是继承RuntimeException，除非有特殊理由才继承Exception。C#中没有Checked Exception的概念，这种推荐的做法等于是采用了C#的设计理念：把是否捕获和何时捕获这个问题交给使用者决定，不强制使用者。当然，如果某些情况下明确提醒捕获更加重要还是可以采用Checked Exception的。对于编写一个方法来讲，“是否在方法上声明一个异常”这个问题比“是否采用Checked Exception”更加重要。

总结

本文介绍了自己总结的Java异常处理的主要原理和原则，主要回答了这几个主要的问题：1)Exception和Error的区别；2)声明异常和未声明异常的区别；3)什么情况下应抛出未声明异常；4)理解如何捕获和处理其他方法抛出的异常；5)自定义异常应继承Exception还是RuntimeException。最后需要说的是，虽然有这些原理和原则可以指导，但是异常处理本质上还是一个需要根据具体情况仔细推敲的问题，这样才能作出最合适的设计。