非受检异常应以预防为主、精准响应、合理封装，多数情况下不建议业务层随意捕获；需通过主动校验、自定义业务异常、全局日志监控等手段提升健壮性。
Java非受检异常（即 RuntimeException 及其子类）不需要强制捕获或声明，但不等于可以放任不管。它们往往暴露的是程序逻辑缺陷，处理的核心不是“兜底捕获”，而是预防为主、精准响应、合理封装。
非受检异常该不该捕获？
大多数情况下不建议在业务层随意 try-catch RuntimeException。原因很直接：
- 空指针、数组越界、类型转换失败等，本质是代码写错了，该修复而不是掩盖
- 盲目 catch(Exception e) 或 catch(RuntimeException e) 容易隐藏 bug，让问题延迟暴露
- 频繁抛出非受检异常有性能开销，不适合作为控制流手段
真正需要捕获的场景极少，比如：调用第三方 SDK 时它内部抛出 IllegalArgumentException，而你已知该情况可安全忽略或重试；或在顶层统一兜底防止进程崩溃（如 Spring 的 @ControllerAdvice）。
更有效的处理方式：提前防御
比起事后 catch，更推荐在源头做校验和约束：
立即学习“Java免费学习笔记（深入）”；
- 用 Objects.requireNonNull() 主动检查 null，抛出明确的 NullPointerException
- 参数校验用 Assert.isTrue() 或自定义 validate() 工具方法，抛出 IllegalArgumentException 并带上下文（如 “userId 不能为空”）
- 集合操作前判断 size() 或 isEmpty()，避免 IndexOutOfBoundsException
- 字符串转换前用正则或 StringUtils.isNumeric() 预判，防止 NumberFormatException
这类做法把错误拦截在发生前，堆栈更短、定位更快，也符合“失败快”的设计思想。
业务异常优先用自定义非受检异常
对于用户行为或业务规则导致的“预期内错误”，比如余额不足、重复提交、权限不足，应定义自己的 RuntimeException 子类：
- 命名清晰，如 InsufficientBalanceException、DuplicateOrderException
- 继承 RuntimeException，不强迫调用方写 try-catch，保持调用简洁
- 构造时传入 errorCode + message + 可选 cause，便于日志追踪和前端识别
- 配合全局异常处理器（如 @RestControllerAdvice），统一返回标准错误格式
这样既区分了系统 bug 和业务拒绝，又避免了受检异常带来的侵入性声明负担。
日志与监控不能少
非受检异常虽不强制处理，但一旦发生，必须留下可追溯痕迹：
- 在全局异常处理器中记录 ERROR 级别日志，包含异常类型、消息、完整堆栈、关键业务参数（脱敏后）
- 对高频非受检异常（如 NPE 在某接口集中出现）配置告警，说明代码存在稳定性风险
- 避免只打印 e.printStackTrace() —— 它不进日志系统，线上几乎不可查
本质上，非受检异常的“处理”，是靠写得更严谨的代码 + 更聪明的日志 + 更早的监控来实现的。
基本上就这些。不复杂但容易忽略。
