ExceptionWrapper不是Java标准类，而是项目或第三方库自定义的异常包装器，需自行实现以保留原始堆栈并补充业务字段如errorCode和context。
ExceptionWrapper 不是 Java 标准库里的类
Java 原生没有 ExceptionWrapper 这个类，它通常是你所在项目或某第三方工具包（比如自研框架、Apache Commons Lang 扩展、或 Spring 封装层）中定义的自定义异常包装器。直接用 new ExceptionWrapper(...) 会编译报错：Cannot resolve symbol 'ExceptionWrapper'。
如果你看到别人代码里用了它，大概率是：
- 项目内部统一定义的包装类，继承自
RuntimeException或Exception - 某个内部 SDK 提供的工具类，用于携带错误码、上下文、原始异常等信息
- 误把其他语言（如 C# 的
ExceptionWrapper）或文档笔误当成了 Java 标准能力
如何手写一个实用的 ExceptionWrapper
多数场景下，你需要自己定义一个轻量级包装器，核心目标是：保留原始异常堆栈、补充业务字段（如 errorCode、messageKey）、支持链式构造。以下是一个典型实现：
public class ExceptionWrapper extends RuntimeException {
private final String errorCode;
private final Map context;
public ExceptionWrapper(String errorCode, String message) {
super(message);
this.errorCode = errorCode;
this.context = Collections.emptyMap();
}
public ExceptionWrapper(String errorCode, String message, Throwable cause) {
super(message, cause);
this.errorCode = errorCode;
this.context = Collections.emptyMap();
}
public ExceptionWrapper(String errorCode, String message, Throwable cause,
MapzuojiankuohaophpcnString, Objectyoujiankuohaophpcn context) {
super(message, cause);
this.errorCode = errorCode;
this.context = context != null ? context : Collections.emptyMap();
}
// getter 省略}
关键点：
- 必须显式调用
super(message, cause)，否则原始异常的堆栈会丢失
-
context 推荐用不可变集合（如 Collections.unmodifiableMap），避免外部篡改
- 不要重写
printStackTrace() —— 默认行为已足够，强行覆盖反而干扰调试
在 Spring 中替代方案更推荐使用 @ControllerAdvice + 自定义异常
如果你用的是 Spring Boot，与其全局搜 ExceptionWrapper，不如用标准异常处理机制。例如：
- 定义业务异常类：
BusinessException（含 errorCode 字段）
- 用
@ControllerAdvice 拦截并统一封装成 JSON 响应
- 原始异常仍可通过
getCause() 获取，日志里保留完整堆栈
这样做的好处是：
- 不侵入业务代码（不用到处
throw new ExceptionWrapper(...)）
- HTTP 状态码、响应结构可集中控制
- 和 Spring 的事务回滚、AOP 等机制天然兼容
容易踩的坑：包装两次导致原始堆栈丢失
常见错误写法：
try {
doSomething();
} catch (IOException e) {
throw new ExceptionWrapper("IO_ERROR", "文件读取失败", new RuntimeException(e)); // ❌ 错！
}这里把 e 包进了一个新的 RuntimeException，再传给 ExceptionWrapper，导致原始 IOException 变成了“cause of cause”，调试时难以定位根因。
正确做法是直接传 e：
throw new ExceptionWrapper("IO_ERROR", "文件读取失败", e); // ✅另外注意：ExceptionWrapper 如果没显式调用父类带 Throwable 的构造函数，也会静默丢弃原始异常。
自定义异常类一旦引入，就得确保所有团队成员理解它的语义边界——它不是万能兜底，而是为了结构化传递错误上下文。别让它变成掩盖问题的黑盒。
