java多catch异常处理核心是按业务语义分层响应：业务级异常（如insufficientbalanceexception）直接用户提示或补偿，资源级异常（如sqlexception）重试/降级/回滚，系统兜底异常（catch exception）仅日志告警；需严格子类在前父类在后、合并语义一致异常、日志带操作/用户id/traceid等上下文、资源用try-with-resources自动清理。
Java中用多catch块处理不同层级的业务异常，核心是让每种异常落到它该去的地方——不是靠堆砌catch，而是按业务语义分层响应。捕获顺序、合并策略、日志上下文和资源清理，四者协同才能真正支撑起可运维的异常治理体系。
按业务层级从具体到宽泛排列catch
每个catch块对应一个明确的业务处置动作，顺序必须严格遵循“子类在前、父类在后”。编译器会强制校验，一旦写反就报错“不可达代码”。
- 业务级异常：如InsufficientBalanceException、InvalidPromoCodeException，直接返回用户提示或触发补偿流程
- 资源级异常：如SQLException、IOException，需重试、降级或重建连接，并配合事务回滚
- 系统兜底异常：catch (Exception e)只能放在末尾，仅用于全量日志记录与告警上报，绝不静默吞掉
合并语义一致的异常，避免重复逻辑
当几种异常需要完全相同的恢复动作（比如统一关闭连接、更新失败指标），可用|语法在一个catch中声明，前提是它们互不继承。
- ✅ 合法：catch (IOException | SQLException e) —— 都代表外部依赖失败，统一做连接释放+错误计数
- ❌ 编译失败：catch (IOException | FileNotFoundException e) —— 后者是前者子类，违反disjoint规则
- ⚠️ 注意：变量e的静态类型是最近公共父类（如Exception），不能直接调用子类特有方法，需先instanceof判断
日志必须带上下文，不能只记异常消息
捕获异常只是起点，真正帮人定位问题的是结构化上下文信息。单纯e.getMessage()或printStackTrace()对排查业务故障基本无效。
- 必填字段包括：当前操作（如"submit_order"）、用户ID、traceId、关键入参（脱敏后）、异常类名
- 推荐方式：在catch块中构造Map或DTO，传给统一日志方法；避免在每个catch里手写重复日志语句
- 敏感数据如密码、token、原始SQL必须过滤，可用正则替换或白名单机制实现脱敏
资源清理不依赖catch顺序，优先用try-with-resources
异常分级解决“怎么响应”，资源治理解决“如何善后”，二者正交但必须协同设计。
- 打开的流、数据库连接、网络套接字等Closeable资源，一律用try-with-resources自动释放，比手动finally更可靠
- 若需在特定catch中执行补偿操作（如手动rollback），应封装为私有方法，在各相关catch块内调用，避免逻辑分散
- 切忌在catch或finally中return或throw新异常——会覆盖原始异常，干扰问题追踪
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
