另一个角度看『异常』

来自:技术琐话(微信号:TheoryPractice),作者:孤尽



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

推荐↓↓↓
Java编程
上一篇:讲讲最大努力通知策略! 下一篇:从时延毛刺问题定位到 Netty 的性能统计设计