将受检异常包装为运行时异常是为了避免强制上层处理底层技术细节，保持API简洁；标准做法是用带原始异常作为cause的RuntimeException或语义化自定义子类（如ConfigLoadException）抛出，关键是要保留栈轨迹并补充业务上下文。
在 Java 中，将 受检异常（checked exception） 在 catch 块中包装为 运行时异常（unchecked exception），是一种常见做法，目的是避免强制上层调用者处理本不该暴露的底层异常细节，同时保持代码简洁和调用链的灵活性。
为什么要转换？
受检异常必须被显式捕获或声明抛出，这有时会破坏 API 的设计意图——比如一个工具方法本应“静默失败”或统一以业务异常形式上报，但底层 IO 或反射操作抛出了 IOException 或 IllegalAccessException。直接 throws 它们会让调用方被迫处理不相关的技术细节。转换为运行时异常（如 RuntimeException 及其子类）可绕过编译检查，由更高层统一兜底处理。
标准写法：用 RuntimeException 包装
最直接的方式是创建一个新的 RuntimeException 实例，并把原始异常作为 cause 传入：
try {
Files.readString(Paths.get("config.txt"));
} catch (IOException e) {
throw new RuntimeException("读取配置文件失败", e);
}
这样既保留了原始异常栈轨迹（便于排查），又消除了受检约束。注意：构造函数中传入 e 是关键，否则会丢失根本原因。
立即学习“Java免费学习笔记（深入）”；
推荐使用更语义化的自定义运行时异常
比起裸用 RuntimeException，定义明确含义的子类更利于维护和诊断：
- 新建一个继承
RuntimeException的类，例如ConfigLoadException - 提供带
String和Throwable的构造器（可复用父类，也可显式定义） - 在
catch中抛出该类型，提升可读性和错误分类能力
示例：
public class ConfigLoadException extends RuntimeException {
public ConfigLoadException(String message, Throwable cause) {
super(message, cause);
}
}
// 使用
try {
loadFromXml();
} catch (JAXBException e) {
throw new ConfigLoadException("XML 配置解析失败", e);
}
避免吞掉异常或丢失上下文
以下做法应避免：
-
throw new RuntimeException();—— 没有消息也没有 cause，调试困难 -
throw new RuntimeException(e.getMessage());—— 丢掉了原始异常的栈和类型信息 - 仅
e.printStackTrace();后静默返回 —— 异常被掩盖，逻辑可能出错却不报警
核心原则：**保留 cause，补充有意义的业务上下文消息**。
