Java中不建议用String拼接替代标准异常链构造，因其导致语义错位、信息丢失、调试困难、违反设计契约；异常链需通过initCause()或带cause构造器维持Throwable对象引用，以支持getCause()追溯、类型捕获、栈展开及工具链集成。
Java中不建议用String拼接替代标准的异常链构造，核心原因在于：语义错位、信息丢失、调试困难、违反异常设计契约。异常不是日志，也不是提示文案，它承载的是可捕获、可分类、可传播、可诊断的结构化错误上下文。
异常链的本质是对象关系，不是字符串组合
标准异常链通过 Throwable.initCause() 或带 cause 参数的构造器（如 new IOException("read failed", cause)）建立父子引用关系。JVM 和调试工具（IDE、日志框架、监控系统）依赖这种引用链：
-
e.getCause()可逐层获取原始异常 -
e.printStackTrace()自动展开完整调用栈和嵌套栈 -
Thread.getStackTrace()、Throwable.getSuppressed()等 API 仅对真实 Throwable 对象有效
若改为new RuntimeException("IO error: " + e.getMessage() + "; caused by: " + e.getClass().getSimpleName())： - 原始异常对象被丢弃，
getCause()返回null - 栈轨迹只剩当前抛出点，丢失根源位置
- 无法区分
IOException和SQLException，类型信息彻底湮灭
String拼接会破坏异常的可处理性
异常处理逻辑往往基于类型匹配（catch (SQLException e)）或属性判断（e instanceof TimeoutException）。拼接后的字符串异常：
- 所有错误都变成
RuntimeException或单一类型，丧失多态捕获能力 - 无法调用原异常的特有方法（如
SQLException.getSQLState()、HttpClientErrorException.getStatusCode()） - 日志脱敏、重试策略、熔断判定等依赖异常类型的机制全部失效
容易引入低级但致命的副作用
-
空指针风险：
e.getMessage()可能为null，拼接后出现"null"字面量，掩盖真实问题 -
栈信息截断：手动拼接时通常只取
getMessage()，丢弃getStackTrace()、getSuppressed()、getLocalizedMessage()等关键数据 - 编码与国际化断裂：原异常可能已按 locale 格式化消息，拼接会强制覆盖为硬编码字符串
正确做法：用标准构造器维护链路
// ✅ 推荐：保留原始异常对象和类型
try {
doNetworkCall();
} catch (IOException e) {
throw new ServiceException("Failed to fetch user data", e);
}
// ✅ 多层包装也保持链路清晰
} catch (ServiceException e) {
throw new BusinessProcessException("Order submission failed", e);
}这样既保留语义层级，又支持任意深度的 getCause() 向下追溯，IDE 调试时也能直接跳转到原始异常位置。
立即学习“Java免费学习笔记（深入）”；
本质上，异常链是程序的“错误拓扑图”，而字符串拼接只是给这张图拍了一张模糊快照。
