catch块应作为业务降级与容错的主动执行点：明确分层降级策略、封装降级逻辑、保障结果安全可用、记录可观测信息以推动根因治理。
在 Java 中，catch 块不该只是打印日志或抛出包装异常，而应成为业务降级与容错的主动执行点。关键在于：明确降级策略、隔离副作用、保障返回结果可用，并避免掩盖真实问题。
明确降级路径，按异常类型分层处理
不同异常代表不同故障场景，需差异化响应：
- 网络超时（如 SocketTimeoutException）：可返回缓存数据、默认值或上一次成功结果
- 服务不可用（如 ConnectException）：切换备用接口、启用本地模拟逻辑，或走兜底静态配置
- 业务校验异常（如 IllegalArgumentException）：通常不降级，而是快速失败并返回友好提示
- 系统级异常（如 NullPointerException）：记录告警，返回通用错误码，避免暴露内部细节
封装降级逻辑，避免 catch 块臃肿
把降级行为抽成小方法或函数式接口，保持可读性和可测性：
// 示例：使用 Supplier 封装降级逻辑
String fallbackData = fallback(() -> {
log.warn("主调用失败，启用本地缓存降级");
return cacheService.getLatest("user_profile");
}, "default_profile");
这样 catch 块只负责捕获和调度，不掺杂具体实现。
确保降级结果安全可用，防止二次异常
降级逻辑本身必须高可靠：
- 降级方法内避免再抛受检异常；若可能失败，应自行 try-catch 并返回兜底值
- 避免在降级中调用同样不稳定的外部依赖（比如又去查一个可能宕机的 Redis）
- 对返回对象做空检查或防御性拷贝，防止 NPE 或状态污染
- 必要时加简单熔断（如“3 分钟内连续 5 次降级则跳过降级直接报错”）
记录可观测信息，为后续优化提供依据
每次降级都是一次信号，要留下足够线索：
- 记录原始异常类型、消息、堆栈（脱敏后）
- 标记是否触发降级、用了哪条降级路径、耗时多少
- 上报指标（如
fallback_count{type="cache",method="loadUser"}） - 对高频降级路径设置告警，推动根因治理而非长期容忍
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
