先给结论
异常的分类
异常可以分为:checked exception和unchecked exception
- unchecked exception
Error和RuntimeException及子类 - checked exception
Throwable中除了以上两种所有子类
一定要捕获或继续向上抛出吗
语法层面:
checked exception,Yes
unchecked exception,No
良好的代码习惯 & 代码鲁棒性层面:
建议Yes,即对于unchecked exception也建议捕获或继续向上抛出。
为什么建议捕获或抛出unchecked exception
看个例子:
因为NPE是RuntimeException子类,所以test()没有进行捕获或抛出也成功编译。
同理,test的调用者,可以选择捕获/抛出,也可以如test方法一样不进行捕获或抛出(实际上,因为test调用者大概率不会阅读test源码,只看方法签名,大概率不会进行捕获或抛出)。
下面比较一下区别。
调用不捕获
运行结果:
可以看到,程序直接终止了——Process finished with exit code 1(正常结束的是code 0),这个进程因为这个Exception中断了,剩下的处理逻辑不再进行。可以对比SpringMVC中@ControllerAdvice + ExceptionHandler,请求处理失败时,Exception被catch,走ExceptionHandler处理逻辑,返回相应的错误码和response(即使是所有特定的Exception都落空 ,还有一个@ExceptionHandler(Exception.class)兜底)。
但是上例中,test()失败后整个进程finished,想象一下,如果是淘宝上一个购买请求走到这里,那么客户端得不到任何有效信息,e.g.
SpringBoot:
Postman:
Chrome:
调用捕获
结果 :
这和下面这个是一模一样的:
二者对比可以看出,如果test()方法内部的确抛出了异常(无论是调用的其他方法还是自己亲自throw new Exception),但是没有在方法签名上加,这样会导致调用者也不知道该方法会产生异常,“正常的外表”会迷惑调用者。考虑到层层调用(如递归依赖等),这样导致的结果可能是灾难性的。
启示
- 作为服务/工具提供者,要做到“异常一定被捕获或继续向上抛出”
让程序所有的处理流程都在可控/预料范围内,提供给调用者的接口也是可靠的,不会出现接口文档之外的输出(Java方法签名本身就是接口文档:这个方法只会抛出>=签名上的异常)。
- 作为服务/工具调用者,第三方的接口使用应慎之又慎
第三方提供的api,client,rpc等等,在catch完方法签名的异常之后,追加一个catch(Throwable e)是比较稳妥的办法。我们可以认为,只有原生的JDK本身是可靠的,其他都有bug的风险。
在实际开发中我们往往兼具两种角色,所以两方面都要注意 。