多catch块需按具体到宽泛顺序捕获异常，针对不同错误类型采取差异化处理策略，并结合业务场景选择恢复方式，同时增强日志与监控可观测性。
多catch块不是语法炫技，而是让程序在面对不同错误时，能做出更精准、更合理的反应。关键在于区分错误类型，给出对应策略，而不是一股脑吞掉异常或统一报错。
按错误类型分层响应
业务中常见多种异常混杂：用户输错格式、除零、数组越界、空指针……每种代表不同问题根源，处理方式也应不同。
- NumberFormatException：说明输入非法，应提示用户“请输入有效数字”，并保留当前操作上下文，允许重试
- ArithmeticException：如除零，属于逻辑边界问题，可默认返回0或NaN，并记录警告日志，不中断流程
- ArrayIndexOutOfBoundsException：通常是代码逻辑缺陷（比如硬编码索引），应记录错误堆栈，触发告警，但对外返回兜底值（如空列表）
避免父类异常“吃掉”子类细节
如果把Exception写在最前面，后面所有具体异常都不会被捕获——因为Java只执行第一个匹配的catch块。
正确顺序必须是：从具体到宽泛。例如：
- 先写
catch (FileNotFoundException e) - 再写
catch (IOException e) - 最后才考虑
catch (Exception e)（通常不建议加，除非做兜底日志）
结合业务场景选择恢复策略
不是所有异常都要“修复”，重点是保障主流程可用性。
- 批量导入Excel时，某一行解析失败 → 单独记录该行错误，继续处理下一行（catch放在循环内）
- 支付扣款接口调用失败 → 区分是网络超时（可重试）还是余额不足（直接拒绝），用不同catch分支走不同补偿路径
- 配置加载失败 → 先尝试读取本地备份配置（catch中降级），再抛出初始化异常终止启动
配合日志与监控增强可观测性
每个catch块里不要只打印e.printStackTrace()，要带业务上下文。
- 记录关键参数（如订单ID、用户ID、请求来源）
- 区分日志级别：用户输入错误用
WARN，系统内部缺陷用ERROR - 对高频异常（如每分钟超过10次的SQLTimeoutException）自动触发监控告警
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
