异常处理原则

Posted 2020-10-06

异常机制是现代主流语言的标配，但是异常处理问题虽然已经被讨论很多，也有很多经典书籍的论述，却一直都充满争议。很多人都觉得异常处理很难拿捏，同时也 难以理解一些语言或库的异常处理设计。我使用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方法：

/**
 * Returns an {@code Integer} object holding the
 * value of the specified {@code String}. The argument is
 * interpreted as representing a signed decimal integer, exactly
 * as if the argument were given to the {@link
 * #parseInt(java.lang.String)} method. The result is an
 * {@code Integer} object that represents the integer value
 * specified by the string.
 *
 * <p>In other words, this method returns an {@code Integer}
 * object equal to the value of:
 *
 * <blockquote>
 *  {@code new Integer(Integer.parseInt(s))}
 * </blockquote>
 *
 * @param      s   the string to be parsed.
 * @return     an {@code Integer} object holding the value
 *             represented by the string argument.
 * @exception  NumberFormatException  if the string cannot be parsed
 *             as an integer.
 */
public static Integer valueOf(String s) throws NumberFormatException {
    return Integer.valueOf(parseInt(s, 10));
}

public static int parseInt(String s, int radix)
            throws NumberFormatException{
    /*
     * WARNING: This method may be invoked early during VM initialization
     * before IntegerCache is initialized. Care must be taken to not use
     * the valueOf method.
     */

    if (s == null) {
        throw new NumberFormatException("null");
    }

    if (radix < Character.MIN_RADIX) {
        throw new NumberFormatException("radix " + radix +
                                        " less than Character.MIN_RADIX");
    }

    if (radix > Character.MAX_RADIX) {
        throw new NumberFormatException("radix " + radix +
                                        " greater than Character.MAX_RADIX");
    }

    int result = 0;
    boolean negative = false;
    int i = 0, len = s.length();
    int limit = -Integer.MAX_VALUE;
    int multmin;
    int digit;

    if (len > 0) {
        char firstChar = s.charAt(0);
        if (firstChar < ‘0‘) { // Possible leading "+" or "-"
            if (firstChar == ‘-‘) {
                negative = true;
                limit = Integer.MIN_VALUE;
            } else if (firstChar != ‘+‘)
                throw NumberFormatException.forInputString(s);

            if (len == 1) // Cannot have lone "+" or "-"
                throw NumberFormatException.forInputString(s);
            i++;
        }
        multmin = limit / radix;
        while (i < len) {
            // Accumulating negatively avoids surprises near MAX_VALUE
            digit = Character.digit(s.charAt(i++),radix);
            if (digit < 0) {
                throw NumberFormatException.forInputString(s);
            }
            if (result < multmin) {
                throw NumberFormatException.forInputString(s);
            }
            result *= radix;
            if (result < limit + digit) {
                throw NumberFormatException.forInputString(s);
            }
            result -= digit;
        }
    } else {
        throw NumberFormatException.forInputString(s);
    }
    return negative ? result : -result;
}

它声明抛出的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) {
        ...
    }
    ....
}

但是，很遗憾有一种很典型的情况是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。最后需要说的是，虽然有这些原理和原则可以指导，但是异常处理本质上还是一个需要根据具体情况仔细推敲的问题，这样才 能作出最合适的设计。

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