异常一定要捕获或继续向上抛出吗

先给结论

异常的分类

异常可以分为：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的风险。

在实际开发中我们往往兼具两种角色，所以两方面都要注意 。