SonarLint 不反对异常链，而是反对破坏链完整性或掩盖原始上下文；必须显式传递原始异常、避免空 cause、禁用重复 initCause()、合理包装且日志不能替代链式传递。
Java异常链（Throwable.initCause() 或带 cause 构造器）本身是合法且推荐的实践，但 SonarLint 对其使用有明确的合规边界——它不反对异常链，而是反对“破坏链完整性”或“掩盖原始上下文”的误用。合规调整的关键，在于保留根因、避免空 cause、统一包装逻辑。
异常链必须显式传递原始异常
SonarLint 会标记类似这样的代码为 java:S1166（Exception handling should preserve original exception）：
try {
riskyOperation();
} catch (IOException e) {
throw new ServiceException("操作失败"); // ❌ 丢失 e
}
正确做法是将原始异常作为 cause 显式传入：
- 优先使用带 cause 的构造器：
new ServiceException("操作失败", e) - 若自定义异常未提供 cause 构造器，需在类中显式调用
initCause(e)，且仅调用一次 - 禁止在 catch 块中新建异常后不设 cause，再手动 log 原始异常——log 不能替代链式传递
禁止对已设 cause 的异常重复赋值
同一个 Throwable 实例的 cause 只能设置一次。SonarLint 会检测 initCause() 被多次调用，或对已有 cause 的异常再次调用该方法，触发 java:S2201。
立即学习“Java免费学习笔记（深入）”；
常见误写：
catch (SQLException e) {
ServiceException se = new ServiceException("DB error");
se.initCause(e);
se.initCause(new RuntimeException("override!")); // ❌ 运行时报 IllegalStateException
}
修复要点：
- 只在异常实例首次创建时设置 cause
- 避免在工具方法中无条件调用
initCause()，应先检查getCause() == null - 推荐用构造器代替
initCause()，更安全且语义清晰
包装异常时需保持语义层级与类型合理性
SonarLint 不鼓励“过度包装”——比如把 IllegalArgumentException 包成 RuntimeException 再包成 ServiceException，尤其当外层异常未增加新上下文时。
合规判断标准：
- 包装后的异常类型应比原始异常更抽象（如从
IOException→DataServiceException），而非更泛化（如 →RuntimeException） - 每层包装必须附带**有意义的新消息**，不能只是原样复制或拼接“failed: ”前缀
- 若原始异常已是业务语义明确的类型（如
InsufficientBalanceException），通常无需再包装
日志 + 异常链需协同，不可互相替代
有人误以为“只要 log 了原始异常，就不必设 cause”，这是 SonarLint 明确反对的。日志只用于调试，异常链用于运行时控制流和上层决策（如重试、降级、告警分级）。
正确组合方式：
- 记录日志时用
logger.error("业务操作失败", e)—— 完整输出栈和 cause 链 - 抛出异常时仍要构造带 cause 的新异常：
throw new BusinessException("支付校验未通过", e) - 避免同时做两件事：
logger.error(..., e); throw new BusinessException(...);却不设 cause —— 这属于典型违规
