核心是用带cause参数的构造器或raise from语法封装异常，必须显式传递原始异常作为cause，避免拼接消息、空catch或丢弃堆栈，确保异常链完整可追溯。
核心是用带 cause 参数的构造器或 raise from 语法创建新异常，原始异常必须作为原因显式传入，不能拼消息、不能空 catch、不能丢弃堆栈。
Java 中正确封装业务异常
DAO 层抛出 DataAccessException，服务层不应直接暴露它。应捕获后新建语义清晰的业务异常，并把原异常作为 cause：
- 自定义异常类需继承
RuntimeException或Exception，并提供Throwable cause构造器（父类通常已支持） - 写法必须是：
throw new UserServiceException("用户注册失败", e);—— 这里e是捕获的原始异常 - 避免错误写法：
throw new UserServiceException("DB error: " + e.getMessage());（丢失 cause 和完整堆栈） - 统一异常处理器中，日志记录要传整个异常对象，例如
log.error("业务异常", ex);，而非log.error(ex.getMessage());
Python 中用 raise from 建立显式链
当底层异常需要转为更贴合业务语义的异常时，raise ... from ... 是标准做法：
- 示例：
try: result = 1 / 0 except ZeroDivisionError as e: raise ValueError("计算参数非法") from e - 执行后 traceback 会清晰显示两段：先是
ZeroDivisionError，再是ValueError，并标注 “During handling of the above exception, another exception occurred” -
from e显式设置__cause__，确保调试时能通过exc.__cause__逐层回溯 - 不要用
raise ValueError("...")单独抛出，否则原始异常仅存于__context__（隐式链），语义不如__cause__明确
关键细节不能忽略
异常链不是自动生效的，依赖开发者主动维护：
- Java 中若使用
initCause()，必须在fillInStackTrace()之前调用，否则可能失效 - 跨层传递时，每层都只做一次封装，不建议多层嵌套包装（如 A → B → C → 业务异常），容易模糊责任边界
- 日志框架输出异常时，确认是否启用完整堆栈打印（如 Logback 的
%ex或 Log4j2 的%throwable{full}） - 自定义异常类中，除非有特殊需求，不要重写
printStackTrace()或getCause()，以免破坏链路
为什么这么做很必要
没有异常链的封装，等于把数据库连接超时、SQL 语法错误、空指针这些底层细节，硬塞进“用户操作失败”这类模糊提示里。运维查日志只能看到最后一句，开发调试得一层层翻代码猜位置。而保留完整链路后，一眼就能看到：业务异常 → DAO 异常 → JDBC 驱动异常 → SocketTimeoutException，路径清晰，根因明确。
