应避免将多个 catch 块盲目合并为单个 instanceof 判断，须严格按“子类优先、父类靠后”排序，每个分支需明确处理动作；对相同处理逻辑的异常优先使用 java 7+ multi-catch；业务强依赖类型时应保留多重 catch 或封装分类逻辑。
把多个 catch 块合并成一个 catch + instanceof 判断，看似简化了代码，但容易引入类型判断遗漏、逻辑耦合、可读性下降等隐性风险。关键不是“能不能做”，而是“怎么做才安全”。
避免 instanceof 漏判或错序
单 catch 中靠 if-else 链判断具体异常类型时，顺序错误会导致子类被父类提前拦截——和多重 catch 的编译检查机制不同，这里完全靠人写，编译器不校验。
- 必须严格按“子类优先、父类靠后”手动排列判断顺序，例如：先
e instanceof FileNotFoundException，再e instanceof IOException，最后e instanceof Exception - 建议在每个分支末尾加
return或明确的break（若在 switch 表达式中），防止意外穿透 - 对自定义异常，要确认其继承链是否与判断顺序一致，尤其当它同时继承了多个接口或中间类时
防止空处理或日志冗余
单 catch 容易让人图省事，只写一个通用日志，丢失异常上下文；也容易因分支太多而漏掉某些类型的处理逻辑。
- 每个
instanceof分支都应有明确动作：记录结构化日志（含异常类型、关键字段）、执行对应恢复策略、或重新抛出带业务语义的包装异常 - 禁止出现无操作的 else 分支或“兜底 catch (Exception e) { logger.warn(…); }”这种模糊处理
- 如果某类异常本该中断流程（如
SecurityException），不能因合并进单 catch 就降级为警告
用 Java 7+ multi-catch 替代部分场景
当多个异常需要**完全相同**的处理逻辑（比如统一记录、统一重试、统一转成 ServiceException），优先用 | 合并，而非 instanceof。
- 语法更简洁：
catch (IOException | SQLException e) - 编译器强制要求这些类型互不继承，天然规避类型覆盖问题
- 捕获变量
e是 final 的，避免误赋值，也提醒你“这是只读上下文” - 适用于日志、监控、熔断等横切逻辑，不适用于需差异化响应的业务分支
重构时保留类型语义的底线
如果业务逻辑确实依赖异常类型做决策（如“文件不存在就创建，权限不足就告警”），强行塞进单 catch 会弱化契约表达力。
- 优先考虑提取私有方法，把异常分类逻辑封装起来，保持主流程清晰
- 必要时保留多重 catch，哪怕只有两个——可读性和可维护性比“看起来少了一行”更重要
- 配合 IDE 的结构高亮和快速导航，多几个 catch 块并不影响开发效率，反而是类型意图最直接的体现
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
