Java中如何正确捕获异常体系中的显式子类异常？

这是个非常典型的Java检查型异常设计问题，咱们结合Java异常体系的设计初衷来拆解两种方案的优劣：

方案一：显式声明所有子类异常 #

这种方案完全贴合Java检查型异常的核心设计理念——让调用方在编译期明确知道所有可能的故障场景，强制针对性处理。

• 👍 优势：
  • 方法签名就是最清晰的文档，其他开发者不用翻看方法内部实现，就能知道需要处理哪些异常类型，代码可读性、可维护性拉满。
  • 编译期强制检查，避免调用方遗漏关键异常的处理逻辑（比如BadRequestException需要返回400响应，ServiceUnreachableException需要触发重试）。
• 👎 劣势：
  • 如果子类异常数量较多，方法签名会变得冗长，看起来不够简洁。
  • 后续新增子类异常时，必须修改方法签名，可能导致调用方需要重新编译甚至调整catch块逻辑。

方案二：仅声明ServiceException，用instanceof判断 #

这种方案更偏向灵活性，但牺牲了检查型异常的核心价值。

• 👍 优势：
  • 方法签名简洁，后续新增子类异常时无需修改方法签名，扩展性稍好。
• 👎 劣势：
  • 编译期无法强制调用方处理具体异常，调用方可能只捕获ServiceException却不做细分处理，埋下逻辑漏洞。
  • catch块内大量的instanceof判断会让代码臃肿，违反开闭原则（新增异常时需要修改原有判断逻辑），也降低了代码的可读性。

最终结论 #

选择哪种方案，核心取决于你的异常场景：

• 如果每个子类异常对应完全不同的处理逻辑（比如不同的HTTP状态码、不同的补救措施），那方案一更符合Java规范——这正是检查型异常被设计出来的目的：明确告知调用方所有必须处理的故障，避免遗漏。
• 如果子类异常的处理逻辑高度一致（只是错误信息/码不同），或者后续会频繁新增异常且大部分可以统一处理，那方案二更适合，但建议在catch块内通过策略模式等方式优化instanceof的判断逻辑，避免代码臃肿。

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