unchecked exception 应用于暴露和阻止编程疏忽导致的不可恢复错误，而非兜底处理；正确做法是预防、提前校验、静态检查、单元测试和监控告警，仅在极少数场景下为控制失败范围而具体捕获。

Unchecked Exception（非检查异常）不适合用来“处理”编程疏忽导致的不可恢复错误，而应该用于**暴露和阻止这类错误继续隐藏在代码中**。Java 的设计哲学是：编程错误（如空指针、数组越界、类型转换失败）不是业务场景，而是 bug，必须修正，而非捕获后吞掉或“恢复”。

为什么不该 try-catch 这类 Unchecked Exception

捕获 NullPointerException、ArrayIndexOutOfBoundsException 或 IllegalArgumentException 并“兜底处理”，往往掩盖真正的问题根源：

• 让 bug 在生产环境静默发生，日志可能不完整，排查成本剧增
• 程序可能进入不一致状态（例如部分更新完成、资源未释放）
• 看似“运行不崩溃”，实则逻辑已错，比立即失败更危险

正确的应对方式：预防 + 快速暴露

重点不在“怎么 catch”，而在“怎么让这类异常尽早、清晰、可定位地抛出”：

• 用断言（assert）或工具类提前校验：比如 Guava 的 Preconditions.checkNotNull()，抛出带上下文信息的 NullPointerException，比原生 NPE 更易定位
• 启用编译期检查：使用 IDE 的空值分析（如 IntelliJ 的 @Nullable/@NotNull）、或 Checker Framework 做静态检查，把部分 NPE 挡在运行前
• 单元测试覆盖边界情况：对 null 输入、空集合、非法参数等显式编写测试，确保异常在测试阶段就抛出并被发现
• 日志 + 监控兜底：全局异常处理器（如 Spring 的 @ControllerAdvice）记录未捕获的 unchecked 异常堆栈，触发告警——这不是为了恢复，而是为了快速响应 bug

什么情况下可以 catch？仅限于明确的、有限范围的拦截

极少数场景下可捕获 unchecked 异常，但目的仍是“控制失败范围”，而非“恢复业务”：

• 解析外部不可信输入时（如用户上传的 JSON），捕获 JsonParseException（属于 unchecked）并返回友好错误提示，避免整个请求线程崩溃
• 插件/脚本沙箱中执行第三方代码，捕获 RuntimeException 防止宿主系统受影响，同时记录异常供后续分析
• 批处理任务中单条记录出错，捕获异常后跳过该条，继续处理其余数据（需确保无状态、无副作用）

关键原则：异常类型要具体，动作要明确

即使要捕获，也应避免宽泛地 catch (RuntimeException e)：

• 只捕获你**明确知道如何安全响应**的具体子类（如 NumberFormatException）
• 每次 catch 后必须做一件事：记录完整堆栈、清理局部资源、返回明确错误码/消息、或重新包装为更上层的业务异常
• 绝不在 catch 块里写空语句、吞异常、或仅打印 “error occurred” 这类无信息日志

不复杂但容易忽略：unchecked 异常是代码的求救信号，听见它，修 bug，而不是给它戴上消音器。