JDK 中定义了一套完整的异常机制，所有异常都是 Throwable 的子类，分为 Error（致命异常）和 Exception（非致命异常）。

异常机制的分类

Error 是一种非常特殊的异常类型，它的出现标识着系统发生了不可控的错误，例如 StackOverflowError、 OutOfMemoryError。针对此类错误，程序无法处理，只能人工介入。

Exception 又分为 checked 异常(受检异常)和 unchecked 异常(非受检异常)。checked 异常是需要在代码中显式处理的异常，否则会编译出错。如果能自行处理则可以在当前方法中捕获异常；如果无法处理，则继续向调用方抛出异常对象。常见的 checked 异常包括 JDK 中定义的 SQLException、ClassNotFoundException 等。 checked 异常可以进一步细分为两类:

无能为力、引起注意型

针对此类异常，程序无法处理，如字段超长等导致的 SQLException，即使做再多的重试对解决异常也没有任何帮助，一般处理此类异常的做法是完整地保存异常现场，供开发工程师介入解决。

力所能及、坦然处置型

如发生未授权异常(UnAuthorizedException)，程序可跳转至权限申请页面。

在 Exception 中，unchecked 异常是运行时异常，它们都继承自 RuntimeException，不需要程序进行显式的捕捉和处理，unchecked 异常可以进一步细分为3 类：

可预测异常(Predicted Exception)

常见的可预测异常包括 IndexOutOfBoundsException、NullPointerException 等，基于对代码的性能和稳定性要求，此类异常不应该被产生或者抛出，而应该提前做好边界检查、空指针判断等处理。显式的声明或者捕获此类异常会对程序的可读性和运行效率产生很大影响。

需捕捉异常(Caution Exception)

例如在使用 Dubbo 框架进行 RPC 调用时产生的远程服务超时异常 DubboTimeoutException，此类异常是客户端必须显式处理的异常，不能因服务端的异常导致客户端不可用，此时处理方案可以是重试或者降级处理等。

可透出异常 (Ignored Exception)

主要是指框架或系统产生的且会自行处理的异常，而程序无须关心。例如针对 Spring 框架中抛出的 NoSuchRequestHa ndlingMethodException 异常，Spring 框架会自己完成异常的处理，默认将自身抛出的异常自动映射到合适的状态码，比如启动防护机制跳转到 404 页面。

综上所述，异常分类结构如图所示：

深入理解异常分类

为了加深理解，下面我们结合出国旅行的例子说明一下异常分类。

第一，机场地震，属于不可抗力，对应异常分类中的 Error。在制订出行计划时，根本不需要把这个部分的异常考虑进去。

第二，堵车属于 checked 异常，应对这种异常，我们可以提前出发，或者改签机票。而飞机延误异常，虽然也需要 check，但我们无能为力，只能持续关注航班动态。

第三，没有带护照，明显属于可提前预测的异常，只要出发前检查即可避免。去机场路上车子抛锚，这个异常是突发的，虽然难以预料，但是必须处理，属于需要捕捉的异常，可以通过更换交通工具应对。检票机器故障则属于可透出异常，交由航空公司处理，我们无须关心。

深入处理异常分类

全面了解了异常分类之后，当遇到需要处理异常的场景时，要明确该异常属于哪种类型，是需要调用方关注并处理的 checked 异常，还是由更高层次框架处理的 unchecked 异常。不论是哪一类异常。如果需要向上抛出，推荐的做法是根据当前场景自定义具有业务含义的异常，为了避免异常泛滥，可以优先使用业界或者团队已定义过的异常。例如，远程服务调用中发生服务超时会抛出自定义的 DubboTimeoutException，而不是直接抛出RuntimeException，更不是抛出Exception 或 Throwable。

在谍战剧里的行动信息传递中，信息的传递方与接收方是需要严格匹配的，比如窗口放置一盆花，表示有紧急异常情况，行动取消；窗帘拉开，表示情况正常，可以行动。一旦传递方信息传递错误，或者接收方理解错误，都会有严重的后果。

同样，异常的抛与接，也一样需要严格的对等传递异常信息机制。我们要使捕获的异常与被抛出的异常是完全匹配的，或者捕获的异常是被抛出异常的父类。

传递异常信息的方式是通过抛出异常对象，还是把异常信息转成信号量封装在特定对象中，这需要方法提供者和方法调用者之间达成契约，只有大家都照章办事，才不会产出误解。推荐对外提供的开放接口使用错误码；公司内部跨应用远程服务调用优先考虑使用 Result 对象来封装错误码、错误描述信息；而应用内部则推荐直接抛出异常对象。

为什么在远程服务调用中推荐使用 Result 对象封装异常信息?

如果使用抛异常的返回方式，一旦调用方没有捕获，就会产生运行时错误，导致程序中断。此外，如果抛出的异常中不添加栈信息，只是 new 自定义异常并加入自定义的错误信息，对于调用端解决问题的帮助不会太大。如果加了栈信息，在频繁调用出错的情况下，信息序列化和传输的性能损耗也是问题。

创作场景

另一个角度看『异常』