nestedruntimeexception用于将受检异常转为运行时异常，避免强制处理，同时保留异常链；推荐用带cause构造器包装，并建议自定义继承它的语义化子类。
Spring 的 NestedRuntimeException 是专为包装受检异常（checked exception）而设计的非受检基类，它让原本必须显式处理的受检异常可以“转成”运行时异常向上抛出，同时保留原始异常链和上下文信息。
为什么需要用 NestedRuntimeException 包装受检异常
Java 要求调用受检异常方法时必须 try-catch 或声明 throws，但 Spring 的许多抽象层（如 DAO、事务管理器、模板类）希望统一用运行时异常表达错误，避免在业务代码中到处写异常处理逻辑。Spring 自身的 DataAccessException、BeanCreationException 等都继承自 NestedRuntimeException，它们内部都封装了原始的 JDBC SQLException、IOException 等受检异常。
如何正确包装：推荐使用带 cause 构造器
NestedRuntimeException 提供了多个构造方法，关键是要传入原始异常作为 cause，才能保持异常栈和嵌套信息：
-
new NestedRuntimeException("读取配置失败", e)—— 推荐，保留原始异常和消息 -
new NestedRuntimeException(e)—— 简洁，但无自定义提示语，不便于定位问题 - 避免只用
new NestedRuntimeException("xxx")（无 cause），这样会丢失原始异常细节
实际使用示例：在 Repository 中包装 IOException
假设你有一个读取本地 JSON 配置的方法，底层抛出 IOException（受检异常）：
public User loadUser(String id) {
try {
String json = Files.readString(Paths.get("user-" + id + ".json"));
return objectMapper.readValue(json, User.class);
} catch (IOException e) {
// ✅ 正确：包装为运行时异常，保留原始异常
throw new NestedRuntimeException("无法加载用户 " + id, e);
}
}
调用方无需 try-catch IOException，但可通过 getCause() 或日志完整追溯到 FileNotFoundException 或 JsonProcessingException 等根本原因。
更优雅的做法：自定义继承 NestedRuntimeException 的异常类
比起直接 new NestedRuntimeException，建议定义语义明确的子类，提升可读性和统一处理能力：
- 创建
ConfigLoadException extends NestedRuntimeException - 构造器中调用
super(message, cause) - 可在 Service 层统一捕获
ConfigLoadException做重试或降级，而不混杂其他运行时异常
这样既符合 Spring 异常体系的设计哲学，也利于团队协作和后期维护。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
