将受检异常包装为运行时异常，本质上是避免上层调用者直接处理底层技术细节，从而保持 API 的清爽与简洁。标准做法包括：使用带原始异常作为 cause 的 RuntimeException，或定义一个语义明确的自定义子类（如 ConfigLoadException）并抛出。核心要点只有两条：保留完整的堆栈轨迹，并补充有意义的业务上下文信息。
Java 中将受检异常（checked exception）在 catch 块里包装为运行时异常（unchecked exception）是一种常见做法。其目的非常明确：防止不应暴露的底层异常细节层层向上传递，迫使每个调用方去处理无关的 IO 或反射错误。这样一来，代码更为简洁，调用链更灵活，上层只需统一进行兜底处理即可。
为什么要转换？
受检异常要么必须显式捕获，要么必须声明抛出，这有时会与 API 的设计初衷产生冲突。例如，编写一个旨在“静默失败”或统一使用业务异常上报的工具方法时，底层 IO 或反射操作可能意外抛出 IOException 或 IllegalAccessException。如果直接通过 throws 抛出，调用方将被迫处理这些与业务无关的技术细节，导致接口变得不友好。通过转换为运行时异常（如 RuntimeException 或其子类），可以绕过编译检查，让更高层统一处理，这是一种更优雅的异常处理策略。
标准写法：用 RuntimeException 包装
最直接的方式是创建一个 RuntimeException 实例，并将原始异常作为 cause 参数传入：
try { Files.readString(Paths.get("config.txt"));} catch (IOException e) { throw new RuntimeException("读取配置文件失败", e);}
这样做的优势在于：原始异常的堆栈轨迹被完整保留，排查问题时不费劲，同时受检异常约束被消除。注意构造函数中一定要传入 e，否则根本原因将丢失，等于白做。
推荐使用更语义化的自定义运行时异常
直接使用 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（根因），并补充有意义的业务上下文信息。做到这两点，异常处理才算到位。
