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 自定义异常并加入自定义的错误信息，对于调用端解决问题的帮助不会太大。如果加了栈信息，在频繁调用出错的情况下，信息序列化和传输的性能损耗也是问题。
