异常捕获顺序应按业务重要性由高到低排列，确保精准逻辑优先命中；子类必须在父类之前，否则编译报错；检查型异常同样需按语义分层；慎用multi-catch，仅当处理逻辑完全一致时适用。
Java异常捕获顺序不是语法排版问题，而是业务逻辑的显性表达——它决定了系统在不同失败场景下如何响应、恢复和反馈。
按业务语义分层，而非仅看继承关系
异常顺序要体现“哪些错更关键、该优先拦截并特殊应对”。比如支付服务中：
- PayBalanceInsufficientException：余额不足，需引导充值，返回明确错误码与前端提示
- PayTimeoutException：第三方超时，应启动异步查单，前端显示“处理中”状态
- RuntimeException：兜底场景，记录完整堆栈+告警，返回通用失败信息
即使三者无直接继承关系，也应按业务重要性由高到低排列，确保精准逻辑优先命中。
子类必须在父类之前，否则编译报错
这是JVM强制要求的语法约束。例如：
- FileNotFoundException 是 IOException 的子类 → 必须先 catch FileNotFoundException，再 catch IOException
- NullPointerException 和 IllegalArgumentException 都是 RuntimeException 子类 → 若同时捕获，二者顺序可互换（无继承关系）
- 但若把 catch(Exception e) 放在最前，后续所有具体异常 catch 块都会变成 unreachable code，编译失败
检查型异常同样适用分层原则
IOException、SQLException 等虽属检查型异常，但业务含义差异显著：
- 捕获 FileNotFoundException → 提示“模板文件缺失，请联系运维”
- 捕获 AccessDeniedException（JDK7+，IOException 子类）→ 提示“权限不足，无法读取目录”
- 捕获 IOException → 统一降级为“操作失败，请重试”，不暴露底层细节
注意：AccessDeniedException 必须放在 IOException 之前，否则会被父类提前吞掉。
慎用 multi-catch 合并处理
像 catch(IOException | SQLException e) 这种写法看似简洁，但会丢失类型语义：
- 如果两个异常对应完全不同的用户提示或补偿动作（如重试 vs 回滚），合并后只能靠 instanceof 再分支，反而增加判断负担
- 分开写 catch 块更清晰、更易维护，也便于未来扩展独立日志策略或监控埋点
- 真正适合 multi-catch 的场景是：多个异常类型需要完全一致的处理逻辑（如统一记录 + 抛出自定义包装异常）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
