多catch块顺序应按业务语义分层而非继承关系，子类异常必须前置以防编译错误和逻辑失效，兜底catch需置于末尾并保留原始堆栈，慎用multi-catch以免掩盖处理差异。

多catch块的顺序不是语法限制的简单排序，而是业务意图的显性表达——它决定了哪类问题该被优先识别、如何响应、是否需要补偿动作。

按业务语义分层，而非仅看继承关系

即使两个异常没有父子继承关系，只要它们在业务中代表不同严重程度或处理路径，就应按实际影响排序。比如支付场景中：

• PromotionInvalidException（优惠券失效）→ 返回明确提示，引导用户更换券
• InventoryShortageException（库存不足）→ 触发降级逻辑，尝试分配替代商品
• RemoteServiceException（下游服务不可用）→ 记录告警，返回“稍后重试”

这种顺序不依赖类结构，而是由用户感知、系统可恢复性、运营干预成本共同决定。

子类必须前置，否则编译失败且逻辑失效

当异常存在继承关系时（如AccessDeniedException是IOException的子类），子类catch必须写在父类之前。否则：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 编译器直接报错：“unreachable catch block”
• 即使侥幸通过（如使用反射绕过检查），运行时也无法进入子类分支
• 真实发生的AccessDeniedException会被IOException捕获，丢失权限语义

兜底catch只放末尾，且必须保留原始堆栈

把catch(Exception e)放在最前，等于提前关闭所有精准处理通道。正确做法是：

• 仅作为最后一道防线，写在所有具体异常之后
• 日志记录必须用log.error("unexpected error", e)，不能只打e.getMessage()
• 避免直接吞掉异常；可根据上下文包装为统一错误响应，但要保留cause链

慎用multi-catch，除非响应逻辑完全一致

写成catch(IOException | SQLException e)看似简洁，但隐含风险：

• 两类异常可能需不同用户提示（“文件读取失败” vs “订单数据异常”）
• 补偿动作不同（重试文件操作 vs 回滚数据库事务）
• 后续若需区分，只能靠instanceof硬判断，破坏类型安全

真正适合合并的场景极少，例如：网络层所有连接类异常都触发熔断，且无需差异化处理。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南