非受检异常通常不应刻意捕获，仅在边界交互、线程兜底、统一上报、资源清理等明确恢复或可观测性场景下谨慎使用；盲目捕获会掩盖缺陷、破坏快速失败原则、干扰契约并隐藏并发问题；应优先通过校验、Optional、业务异常建模等防御性设计规避。
非受检异常（Unchecked Exception）指继承自 RuntimeException 或 Error 的异常，编译器不强制要求处理。虽然可以 try-catch 捕获它们，但**刻意捕获非受检异常通常不是好做法**，需结合具体场景谨慎判断。
哪些场景下可能需要捕获非受检异常
并非所有捕获都错误，关键看是否具备明确的恢复逻辑或可观测性增强需求：
-
边界清晰的外部交互点：如解析用户输入的 JSON 字符串时捕获
JsonParseException（属于RuntimeException），转为友好的提示信息并继续流程； -
防止线程意外终止：在
Thread.UncaughtExceptionHandler之外，对关键工作线程的主循环做顶层catch (RuntimeException e)，记录日志后重启任务，避免静默失败； -
统一异常转换与上报：Web 层（如 Spring 的
@ControllerAdvice）捕获NullPointerException等，封装为标准错误响应，并触发告警，而非让 500 直接暴露给调用方； -
资源清理兜底：在
finally不足以保障时（如异步回调中），对可能抛出IllegalStateException的状态校验做局部捕获，确保后续清理逻辑执行。
盲目捕获非受检异常的主要风险
掩盖问题本质，干扰系统稳定性和可维护性：
-
隐藏程序缺陷：捕获
NullPointerException后仅打印日志却不修复空指针源头，导致相同 bug 在别处重复发生； -
破坏失败快速暴露原则：本该崩溃以暴露严重问题（如
OutOfMemoryError）却被静默吞掉，使系统进入不可预测的中间状态； -
干扰调用链语义：上游方法声明不抛异常，下游却因捕获
IllegalArgumentException而改变行为，违背契约，增加调试成本； -
掩盖并发问题：捕获
ConcurrentModificationException并忽略，可能意味着集合被多线程误用，真正问题未被定位。
更合理的替代方案
优先通过设计和防御性编程规避，而非依赖捕获：
- 用
Objects.requireNonNull()、Preconditions.checkArgument()等提前校验，让问题在调用栈更上层、更易定位的位置暴露； - 对第三方 API 返回值做空/状态检查，而不是等它触发
RuntimeException； - 用 Optional 表达可能为空的返回，减少
NullPointerException场景； - 将可预期的“业务异常”建模为受检异常或自定义业务异常类（即使不强制检查），提升调用方感知度。
捕获非受检异常不是语法错误，而是设计信号——它往往说明代码契约不清、边界模糊或错误处理策略缺失。重点不在“能不能捕”，而在“该不该捕”以及“捕了之后是否真正解决问题”。
