异常处理原理和原则

标签：io   使用   java   for   sp   strong   文件   on   问题   

异常机制是现代主流语言的标配，但是异常处理问题虽然已经被讨论很多，也有很多经典书籍的论述，却一直都充满争议。很多人都觉得异常处理很难拿捏，同时也难以理解一些语言或库的异常处理设计。我使用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声明了MyException，但是它的实现中可能抛出RuntimeException，这是什么意思呢？

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

根据上面提到的原理，未声明异常是和实现相关的，有可能随着不同实现而出现或消失，同时它又对应不到MyException。比如，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。最后需要说的是，虽然有这些原理和原则可以指导，但是异常处理本质上还是一个需要根据具体情况仔细推敲的问题，这样才能作出最合适的设计。

异常处理原理和原则

标签：io   使用   java   for   sp   strong   文件   on   问题   

原文地址：http://www.cnblogs.com/weidagang2046/p/exception-handling-principles.html