全方法捕获异常仅抛出BusinessException的设计是否存在客观问题？

具体问题如下：

• 无条件捕获Exception的逻辑本身就有严重隐患
  catch(Exception)会捕获所有预期外的异常，包括InterruptedException（线程中断信号，捕获后不处理会导致线程池异常）、NullPointerException这类代码bug、甚至是OOM等错误的包装异常，全部封装成BusinessException之后，根本没法通过异常类型区分问题性质。而且示例代码里的多层嵌套捕获，会把内层抛出的BusinessException再次包装，栈跟踪信息层层嵌套，排查线上问题时要翻多层cause才能找到根因，甚至如果漏传根异常参数，会直接丢失原始报错信息，大幅提升排查成本。
• 和现有Spring Boot全局异常处理机制完全冲突
  项目已经配置了@ControllerAdvice做统一异常处理，本来就可以实现「对外隐藏底层异常细节、统一返回格式」的需求，完全不需要每个方法单独写异常捕获逻辑。全局异常处理器可以根据不同的异常类型返回对应的HTTP状态码、错误提示、日志级别，现在全部改成BusinessException之后，等于废掉了全局处理的分类能力，只能靠给BusinessException加错误码区分场景，反而要额外维护全量错误码映射，平白增加开发成本。
• 不必要的性能和维护开销
  异常实例化本身就有不小的性能开销，多层包装会重复生成异常对象，在高并发场景下会带来不必要的性能损耗。而且每个方法都要写一大堆嵌套try-catch模板代码，可读性极差，后续修改业务逻辑还要对应调整异常捕获结构，维护成本翻倍。

合理的异常处理思路参考 #

• 业务逻辑中只在需要附加额外业务上下文的场景，才把底层异常包装成BusinessException，比如调用第三方接口失败时，把第三方返回的错误信息附加到业务异常里，不需要每个方法都做统一包装。
• 其余场景该抛出什么类型的异常就抛什么，参数错误抛IllegalArgumentException、IO操作失败抛IOException即可，不需要手动捕获。
• 所有异常统一交给全局异常处理器处理，在处理器中统一封装对外返回的格式、打印日志，既可以做到对外隐藏底层实现细节，也能保留完整的异常信息方便内部排查。

内容的提问来源于stack exchange，提问作者Joe Caruso