Java中包装异常的核心目的是保留原始错误上下文并提供业务语义。需通过cause链式传递、分层封装（DAO→Service→API）、避免重复包装与吞没，并为自定义异常添加结构化字段以增强可维护性。
在Java中包装异常（Exception Wrapping）的核心目的是保留原始错误上下文的同时，提供更清晰、更有业务意义的异常信息。不是简单地“套一层”，而是要有意识地传递因果关系、隐藏实现细节、统一异常体系，并便于日志追踪和上层处理。
用构造函数链式传递原始异常（Cause Chaining）
这是最基础也最重要的包装方式。通过将原始异常作为 cause 传入新异常的构造函数，既保留了完整的堆栈轨迹，又让新异常承载业务语义。
- 推荐使用带
Throwable cause参数的构造函数，例如：throw new BusinessException("订单支付失败", e); - 避免只传消息而丢弃 cause：
throw new BusinessException("订单支付失败"); // ❌ 丢失原始异常信息 - JVM 会自动将 cause 的堆栈打印在
Caused by:后面，调试时一目了然
按层级封装：区分技术异常与业务异常
不要把所有异常都包装成同一种类型。应建立分层的异常结构：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
-
底层（DAO/SDK 层）：捕获并包装技术异常（如
SQLException,IOException），转为带 cause 的自定义异常，例如DataAccessException -
服务层（Service）：进一步包装为业务语义明确的异常，如
InsufficientBalanceException或InvalidOrderStatusException，此时可补充业务字段（如订单号、用户ID）到异常消息或扩展字段中 - API 层（Controller）：不建议在此层再包装；而是统一做异常翻译，转为标准响应（如 HTTP 400/500 + 错误码 + 提示语），原始异常记录日志即可
避免过度包装和吞没异常
包装不是越多越好，关键看是否增加价值：
立即学习“Java免费学习笔记（深入）”；
- ❌ 不要重复包装同一异常多次（比如 Service 捕获后包装，Controller 又包装一次），会导致 cause 链冗长难读
- ❌ 不要在 catch 块里只写
e.printStackTrace()或空 catch，这等于吞掉异常，后续无法诊断 - ✅ 如果异常已具备足够上下文且上层能直接处理，可直接抛出，无需额外包装
- ✅ 日志中建议记录原始异常的完整堆栈（用
log.error("xxx", e)而非log.error("xxx " + e.getMessage())）
增强可维护性：为自定义异常添加结构化字段
比纯字符串消息更可靠的方式，是让异常本身携带可编程提取的信息：
- 定义业务异常类时，加入字段如：
private final String errorCode;、private final Map<string object> context;</string> - 构造时传入：
new BusinessException("BALANCE_INSUFFICIENT", Map.of("orderId", "20240501123", "balance", 12.5)) - 这样下游可通过异常类型和字段做精准处理（如前端根据
errorCode展示不同提示），也方便监控系统按码聚合告警
