在Java开发里，底层框架或第三方库抛出的异常通常带有技术细节，如果直接往上层传，调用方很难判断业务上到底出了什么问题。将异常信息封装并重新抛出，本质是把技术异常转成具有业务含义的异常，同时保留原始错误线索，方便后续排查。
为什么需要封装并重新抛出异常
真实系统中，数据访问层可能抛出SQLException，远程调用可能抛出IOException。这些异常对业务逻辑层没有意义，反而暴露了实现细节。通过封装，我们可以定义如OrderNotFoundException、PaymentFailedException这类异常，让上层只关心业务结果。
另外，直接丢弃原始异常只抛一个新message是很多初学者容易犯的错。这样做会导致排查问题时丢掉最关键的堆栈和根因。Java的异常链设计正是为了解决这一问题，它允许新异常持有原异常引用，打印堆栈时会逐级展开。
自定义异常的设计方式
推荐让自定义异常继承RuntimeException或Exception，并提供接收cause的构造器。下面代码展示一个典型的业务异常定义：
public class BusinessException extends RuntimeException {
// 错误码，便于前端或日志区分
private final String errorCode;
public BusinessException(String errorCode, String message) {
super(message);
this.errorCode = errorCode;
}
// 接收原始异常作为cause，保留异常链
public BusinessException(String errorCode, String message, Throwable cause) {
super(message, cause);
this.errorCode = errorCode;
}
public String getErrorCode() {
return errorCode;
}
}
上面代码中，第二个构造器调用了父类RuntimeException(String, Throwable)，把原始异常设置为cause。这样在日志中通过printStackTrace就能看到完整链路，从业务异常一直追溯到SQL异常。
如果某些场景不能修改构造器，也可以使用initCause方法，但要在异常创建后尽快调用，且一个异常只能设置一次cause，重复设置会抛IllegalStateException。日常开发中优先使用带cause的构造器，更直观也不易出错。
封装并重新抛出的具体写法
在捕获底层异常后，最常见的封装重抛模式如下：
public Order queryOrder(long orderId) {
try {
return orderMapper.selectById(orderId);
} catch (SQLException e) {
// 封装为业务异常，并传入原始e作为cause
throw new BusinessException("ORDER_001", "查询订单失败，订单号：" + orderId, e);
}
}
这段代码在catch块中构造了BusinessException，把SQL错误包装进去。调用方捕获到的将是BusinessException，但通过getCause()能拿到SQLException，既隐藏了细节又没丢根因。
还有一种情况是在已有异常上补充信息而非完全新建类型。可以使用Throwable的addSuppressed方法保留被压制异常，或者简单包装一层。示例如下：
try {
doTask();
} catch (IOException e) {
IOException wrapper = new IOException("任务执行中断", e);
// 若还需记录另一个关联错误
wrapper.addSuppressed(new RuntimeException("清理资源失败"));
throw wrapper;
}
addSuppressed适合在try-with-resources场景里补充关闭资源时的错误，不会覆盖主要异常，打印时以Suppressed形式列出，对排查复合故障很有帮助。
常见误区与注意点
第一个误区是吞掉原异常只抛新message。例如catch里写throw new BusinessException("出错了")，这样原始堆栈完全消失，线上问题无法定位。第二个误区是过度封装，把每一种小错误都定义新异常类，导致异常体系膨胀难以维护。
还要注意异常类型的选择。如果方法签名声明了throws SQLException，就不要偷偷改成抛RuntimeException逃避检查异常，这会破坏接口契约。应当评估是否真的需要转换为非检查异常，或者在方法上声明新的业务异常。
| 做法 | 优点 | 风险 |
|---|---|---|
| 构造器传入cause | 保留完整异常链，代码清晰 | 需提前设计好异常类 |
| initCause补设 | 兼容无cause构造器的异常 | 只能设一次，易漏写 |
| 仅抛新message | 写法简单 | 丢失根因，强烈不建议 |
小结
将异常信息封装并重新抛出，核心是利用异常链保留cause，用业务语义清晰的异常替代底层技术异常。合理设计自定义异常、在catch中正确传入原始异常、避免吞掉堆栈，是写出可维护Java代码的基础能力。
在复杂系统里，还可以结合日志框架，在封装处记录带traceId的告警，而向上抛出时只带用户可读信息。这样运维和开发两侧都能各取所需，既安全又高效。