解读Kevin Bourrillion观点：强制捕获unchecked exception的API及SOAP场景疑问

咱们先聊聊为什么Kevin Bourrillion会得出“任何强制开发者捕获unchecked exception的API本身存在缺陷”这个结论：

• 违背unchecked exception的设计初衷：在Java这类语言里，unchecked exception（比如NullPointerException、ArrayIndexOutOfBoundsException）的定位是编程错误或者不可恢复的系统级故障。这类问题的正确解决方式是从根源修复代码，而不是在运行时捕获掩盖。如果API强制开发者捕获这类异常，等于引导开发者跳过真正的问题，反而会让代码里埋下更多隐性bug。
• 导致代码冗余与可读性下降：强制捕获unchecked exception会让代码里充斥大量无意义的try-catch块——很多开发者为了满足API要求，会写空的catch块或者仅仅打印一句日志就完事。这不仅增加了代码量，还会让真正需要关注的异常处理逻辑被淹没，降低代码的可读性和可维护性。
• 混淆异常处理的责任分层：unchecked exception大多是底层系统的严重问题，比如数据库连接突然中断、JVM内存不足，上层业务代码根本没有能力修复这类问题。如果API强制上层捕获，等于把不属于上层的处理责任硬推过去，违背了异常处理的分层原则。

再来说说Web Service调用抛出SOAP Fault Exception的场景，Kevin的观点在这里并不成立，原因如下：

SOAP Fault Exception本质上是远程服务调用过程中的预期异常，比如业务参数不符合远程服务要求、远程服务暂时不可用、权限验证失败等。这类异常不是编程错误，而是业务流程中完全可能出现的正常情况，需要上层业务代码根据具体场景做出针对性处理（比如重试请求、给用户返回友好提示）。

通常来说，成熟的Web Service框架会将SOAP Fault Exception设计为checked exception，这完全符合checked exception的设计意图——提醒开发者必须处理这类预期的异常。这时候API要求开发者捕获是合理的，和Kevin所批判的“强制捕获unchecked exception”的情况完全不同。哪怕有些框架将其设计为unchecked exception，但只要这类异常是需要业务处理的，那更合理的做法是将其改为checked exception，而不是强制捕获unchecked异常——不过实际中几乎不会有框架这么设计SOAP Fault。

内容的提问来源于stack exchange，提问作者Farhan stands with Palestine