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，而不是给它戴上消音器。
