异常重抛与包装：Java中的两种异常处理策略

1. 概述

Java 中的 throw 关键字用于显式抛出异常，无论是自定义异常还是内置异常。但在实际开发中，我们常常在 catch 块中捕获异常后，需要再次将其抛出——这就是所谓的异常重抛（re-throwing）。

然而，重抛并不是唯一的选择。有时候我们希望对原始异常进行封装，以便上层调用者能更好地理解业务上下文。这就引出了两种常见做法：

✅ 直接重抛原始异常
✅ 将原始异常包装成新的、更具体的异常

本文将深入对比这两种方式，帮你避开日常开发中的“异常处理踩坑”。

2. 异常重抛（Re-throwing Exceptions）

在某些场景下，我们希望在异常向上传播前做一些清理或记录工作，比如：

回滚数据库事务
记录错误日志
发送告警邮件

完成这些操作后，再把异常原封不动地抛给上层处理。这种做法就是异常重抛。

来看一个简单示例：

String name = null;

try {
    return name.equals("Joe"); // 触发 NullPointerException
} catch (Exception e) {
    // 可以在这里做日志记录等操作
    System.err.println("发生异常：" + e.getMessage());
    throw e; // 重新抛出原始异常
}

输出结果如下：

Exception in thread "main" java.lang.NullPointerException
  at com.example.RethrowSameExceptionDemo.main(RethrowSameExceptionDemo.java:16)

⚠️ 注意：虽然我们在 catch 块中处理了异常，但最终抛出的是原始异常对象。因此，堆栈信息（stack trace）保持不变，依然是异常最初发生的位置。

这对于调试非常友好——你能准确知道问题出在哪一行。

但也有局限性：上层调用者看到的只是一个通用异常（如 Exception 或 RuntimeException），无法直观判断这个异常在当前业务中的含义。

3. 异常包装（Wrapping Exceptions）

为了提升异常的语义清晰度，我们可以选择将原始异常包装进一个新的、更具业务意义的异常中。

Java 提供了构造器支持：大多数异常类都接受一个 Throwable cause 参数，用来保存原始异常。

示例代码如下：

String name = null;

try {
    return name.equals("Joe"); // 触发 NullPointerException
} catch (Exception e) {
    // 记录日志或其他处理
    System.err.println("校验用户名失败");
    
    // 包装成更具体的异常
    throw new IllegalArgumentException("用户名不能为空", e);
}

此时控制台输出为：

Exception in thread "main" java.lang.IllegalArgumentException: 用户名不能为空
  at com.example.RethrowDifferentExceptionDemo.main(RethrowDifferentExceptionDemo.java:24)
Caused by: java.lang.NullPointerException
  at com.example.RethrowDifferentExceptionDemo.main(RethrowDifferentExceptionDemo.java:18)

✅ 关键点：

外层是 IllegalArgumentException，携带了清晰的业务提示
内层通过 Caused by 显示了原始异常 NullPointerException
堆栈信息完整保留，便于排查根源

这种方式被称为异常链（Exception Chaining），它既保留了底层错误细节，又向上暴露了更有意义的错误类型。

4. 如何选择？场景对比

场景	推荐方式	理由
公共库/框架内部错误转换	✅ 包装异常	将底层技术异常转为领域相关异常，避免暴露实现细节
服务层校验失败	✅ 包装异常	抛出 `InvalidRequestException` 等业务异常，便于统一处理
仅需记录日志后继续传播	✅ 重抛原始异常	不改变异常类型，保持堆栈纯净，适合透明传递
跨模块调用需统一异常体系	✅ 包装异常	统一对外暴露的异常类型，提升 API 可维护性

⚠️ 踩坑提醒

❌ 错误做法：

catch (Exception e) {
    throw new RuntimeException("出错了"); // 丢失了原始异常！
}

这样会导致原始异常丢失，后续无法通过 getCause() 获取根因，属于“断链”操作，强烈不推荐。

✅ 正确姿势：

catch (Exception e) {
    throw new BusinessException("业务处理失败", e); // 保留 cause
}

5. 总结

对比项	重抛异常	包装异常
是否保留原始异常	✅ 是	✅ 是（作为 cause）
堆栈信息是否完整	✅ 完整	✅ 完整
上层能否感知原始异常	✅ 可以	✅ 可以（通过 getCause）
语义表达能力	❌ 较弱	✅ 更强（可定制 message 和类型）
适用场景	日志记录、透明传递	业务抽象、异常转换

📌 核心建议：

如果只是想记录日志或执行清理动作，直接重抛最简单粗暴；
如果你想让调用方清楚“这是什么业务出了问题”，那就包装成有意义的异常。

合理使用异常包装，不仅能提升代码可读性，还能让整个系统的错误处理更加结构化和可维护。

示例项目源码已托管至 GitHub：https://github.com/example-java/exception-handling-demo

Persistence

REST

Security