非受检异常（如NullPointerException）本质是代码缺陷，需优先预防而非依赖catch；应通过null判定、集合判空、索引校验等手段从源头避免，发生时则需快速定位、安全降级、保留上下文。
运行期不可预期异常，比如 NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException 等，都属于非受检异常（Unchecked Exception），它们继承自 RuntimeException，编译器不强制你捕获——但一旦发生，程序就会中断执行。
这类异常往往源于逻辑疏漏：对象未初始化就调用方法、集合取值前没判空、数组下标硬编码越界、接口入参校验缺失等。靠 catch 捕获不是首选方案，预防才是核心；而当它真的发生了，catch 的目标不是“吞掉错误”，而是快速定位、安全降级、保留上下文。
优先预防，而非依赖 catch
非受检异常本质是代码缺陷，不是外部不确定性。与其在出错后补救，不如从源头掐断： - 所有对象引用在调用前做 null 判定（或用 Optional 封装） - 集合操作前检查 size() 或 isEmpty() - 数组/列表访问前校验索引范围：`if (i >= 0 && i 预防到位，90% 的 NPE 和 IndexOutOfBounds 根本不会走到 catch 这一步。真要 catch，必须精准且带上下文
如果因兼容旧逻辑、第三方 SDK 行为不可控等原因，不得不捕获运行时异常，务必避免泛化写法： - ❌ 不要写 `catch (Exception e)` 或 `catch (RuntimeException e)` —— 它掩盖真实问题，破坏故障隔离 - ✅ 按具体异常类型分块捕获，每个 catch 处理一类明确语义的失败场景例如处理用户提交的 JSON 数据解析 + 转换流程：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
try {
JsonNode node = objectMapper.readTree(input);
String name = node.path("name").asText(); // 可能 NPE（若字段不存在且未设默认）
int age = node.path("age").asInt(); // 可能 NumberFormatException（若值非数字）
try {
User user = new User(name, age); // 构造函数可能抛 IllegalArgumentException
} catch (IllegalArgumentException e) {
log.warn("用户参数校验失败，name='{}', age={}", name, age, e);
throw new BadRequestException("用户信息格式错误", e);
}
} catch (JsonProcessingException e) {
log.error("JSON 解析失败，原始输入: {}", input, e);
throw new BadRequestException("请求数据格式非法", e);
} catch (NullPointerException e) {
log.error("JSON 字段缺失导致空指针，检查必填字段: name/age", e);
throw new BadRequestException("缺少必要参数", e);
}关键点：每种异常对应一个可理解的业务含义，并附带关键变量快照（如 `name`、`age`、`input`），方便排查。
绝不静默吞异常，日志 + 明确响应
运行时异常一旦发生，说明程序已处于非预期状态。此时： - 不能只写 `e.printStackTrace()` 或 `System.out.println()` —— 生产环境无日志聚合时等于没记 - 不能只 `catch {}` 空处理 —— 错误被丢弃，下游逻辑可能基于错误状态继续执行，引发雪崩 - 必须使用日志框架（如 SLF4J）记录 ERROR 级别日志，且传入异常对象本身（保留堆栈） - 同时向调用方返回清晰、安全的响应（如 HTTP 400 + 友好提示），避免暴露内部实现细节示例合规日志写法：
```java log.error("订单创建失败：用户ID={}，商品SKU={}，库存服务返回空响应", userId, sku, e); ```finally 不适合处理运行时异常的善后
`finally` 块用于资源释放（如关闭流、归还连接），它不解决“异常怎么响应”“数据怎么兜底”的问题。 对运行时异常而言，更关键的是： - 在 catch 中完成状态补偿（如回滚内存缓存、标记任务失败） - 触发告警（如调用监控系统上报） - 启动异步修复流程（如将失败消息投递到死信队列）这些动作应放在 catch 块内显式编写，而不是塞进 finally —— 因为 finally 不知道发生了什么异常，也无法区分处理逻辑。
