关于Exception异常处理的建议

我们在处理异常的时候，时刻需要问自己以下三个问题：

哪里会发生异常？
谁来处理异常？
如何处理异常？

一、异常的分类

Java中的异常主要分为Error和Exception，它们都是Throwable的子类，具体的区别如下：

Error表示系统在运行过程中，发生了不可控的错误，程序无法自己处理，需要人工进行干预，比如重启、加内存、更换服务器等。主要的代表有StackOverflowError、OutOfMemoryError，它们不需要也不允许被程序捕获和处理，一旦发生，系统立即崩溃。
Exception又可以分为两类。
- 编译型异常，又称检查型异常。在程序进行编译的时候就会检查出来的异常，通常IDE都会提示开发人员进行处理。主要代表有ClassNotFoundException、IOException、SQLException等，它们都需要开发人员在程序中显示地对它们进行处理。
- 运行时异常，它们都是RunTimeException的子类，编译时不会被检查出来，等到程序运行时才会被发现的异常。主要代表有NullPointerException、ClassCastException、OutOfBoundsException等。

下面是一张关于异常的继承关系图，可以帮助我们更好地理解它们之间的关系：

Java中的异常继承关系

二、抓取异常

2.1 try-catch-finally

一个常见的抓取异常代码模板如下：

        try {
            // 可能会抛出异常的逻辑
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            // 资源回收操作
        }

2.2 try-with-resource

这是一个语法糖，其实就是自动调用资源的close方法，省去开发人员写finally方法，大致的代码模板如下：

        try (/*资源的初始化*/) {
            // 可能会抛出异常的逻辑
        } catch (Exception e) {
            e.printStackTrace();
        }

此处只是简单说明，具体而详细的使用已经在另一篇文章《如何在try代码块中合理地关闭资源》中阐述了。

三、处理异常

3.1 DAO层

与数据库交互的DAO层往往会抛出各种各样的异常，通常不需要为每一种异常都建立对应的自定义业务异常，会显得很繁杂。

我们应该将DAO层的异常统一封装为DAOException然后再向上抛出，然后在业务层接受这些异常的时候，可以把异常堆栈打印出来，如此也能清晰地定位到具体的原因，比如下面的示例：

public Long generateOrderId(Long userId) throws DAOException {
    try {
        ...
    } catch (Exception e) {
        throw new DAOException("generateOrderId error, userId=" + userId, e);
    }
}

以上代码简单地描述了异常的信息，并给出了出错的userId，还把错误堆栈也一块向上throw，这才是标准的易于定位的异常处理方式。

然后，在业务层捕获异常的时候需要开发者自己判断，当前的异常是否在该方法的处理能力范围之内？如果是，那就可以自己默默把异常的情况处理掉，如果不是，则需要继续向外抛出，给能处理这个异常的调用方去处理。

严禁捕获异常后什么也不处理或者只打印一行日志。因为不处理的话会导致当前请求处理过程中断，很可能直接就将异常堆栈返回给给调用者，体验极差。而打印一行日志而没有堆栈信息的话，则完全无法定位异常发生的根本原因是什么，大大增加了排查的难度。

所以，如果是需要向上抛出的异常，一定要在异常对象中添加上下文参数、局部变量、环境信息等，不可只是简单地一句话了事，会增加问题的排查难度。

3.2 Service层

Service层通常承担着对调用方返回数据的责任，返回什么格式的数据（异常）在不同的场景下是不同的，通常有以下的建议：

对外提供的开放接口使用错误码的返回方式；
公司内部跨应用的远程服务调用使用Result对象来封装错误码和具体的错误信息；
应用内部则直接抛出异常对象即可。

通常，我们在业务层都会抛出表示特定业务逻辑出错的自定义异常，比如“账号密码验证错误异常”、“查询条件为空异常”等。这样做的好处是，一目了然就知道程序发生异常的业务原因是什么。

但是，为了避免自定义异常的泛滥，可以优先使用业界或者团队内已经定义过的异常，其次再使用根据业务场景自定义的异常类，不建议使用Java中原生的异常类直接进行异常的抛出。

最后要说的是，调用方和服务方往往会因为谁来处理异常这件事吵得不可开交，按照业界的开发规范，异常的处理通常都是调用方需要处理的，服务方可以不处理，但必须要有所说明，提示调用方。