Java异常链需用带cause参数的构造器显式包装原始异常，确保getCause()链完整、printStackTrace()显示“Caused by”层级；自定义异常必须提供message+cause双参构造器；避免静默截断、拼接消息或误用initCause。
Java 异常链要完整传递底层原始错误原因，核心是**用带 cause 参数的构造器显式包装，不拼接、不静默、不覆盖堆栈**。只要原始异常对象被原样传入新异常的构造函数，JVM 就会自动维护 getCause() 链，并在 printStackTrace() 中显示清晰的 “Caused by” 层级。
必须用带 cause 的构造器创建新异常
所有 Throwable 子类（包括 RuntimeException、Exception 及自定义异常）都提供 public XxxException(String message, Throwable cause) 构造方法。这是唯一推荐的链式构建方式。
- ✅ 正确：throw new ServiceException("订单提交失败", e);
- ❌ 错误：throw new ServiceException("订单提交失败: " + e.getMessage()); —— 丢失堆栈、丢失嵌套 cause
- ❌ 不推荐：new ServiceException("订单提交失败").initCause(e); —— initCause 只能调用一次，且易被后续代码意外覆盖
自定义异常必须提供 cause 构造器
如果你写了 BusinessException 或 StorageUploadException，它不能只有 BusinessException(String msg)。必须显式声明并委托父类：
- public BusinessException(String message) { super(message); }
- public BusinessException(String message, Throwable cause) { super(message, cause); }
否则上游捕获后无法传 cause，链在第一层就断了。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
避免三类“静默截断”操作
即使用了正确构造器，以下行为仍会让原始原因在日志或调试中不可见：
- 在 catch 块里只调用
e.printStackTrace()或log.error("", e)，然后 return 或 throw 新异常却不传 cause - 用 Optional.orElseThrow(() -> new XxxException("xxx")) 包装时，原始异常已存在，却未将其作为 cause 传入
- 在异步回调（如 CompletableFuture.handle）或消息监听器中捕获异常后，仅记录日志而未 re-throw 带 cause 的封装异常
验证是否真正生效
最直接的方式：对最终抛出的异常调用 e.printStackTrace()，观察输出中是否有缩进的 “Caused by:” 行：
- 有类似
Caused by: java.net.ConnectException: Connection refused→ 链完整 - 只有一层堆栈，无 “Caused by” → 链已断裂，需回溯哪一层漏传了 cause
也可在调试器中展开异常对象，逐层调用 e.getCause()，直到返回 null，确认是否抵达最底层原始异常。
