java异常链的核心是分层契约，通过封装升维实现错误隔离：dao转dataaccessexception、service转orderexception、controller返回标准json，全程保留根因cause。
Java中利用异常链构建多层架构系统错误隔离墙，核心不是堆叠 try-catch，而是用异常链做“上下文锚定”和“责任切分”。它让每一层只关心自己该处理的问题，不透传、不掩盖、不丢失根源信息。
一、异常链不是补丁，是分层契约的载体
在 Controller → Service → DAO → 外部 SDK 的调用链中，各层职责不同：Controller 负责协议转换与用户反馈，Service 负责业务规则校验，DAO 负责数据存取语义。若某层直接 throw new RuntimeException("DB error")，就等于把底层技术细节裸露给上层，破坏了隔离性。
正确做法是用异常链封装并升维：
- DAO 层捕获 SQLException，包装为 DataAccessException("订单查询失败", e)，保留 cause
- Service 层捕获该异常，再包装为 OrderException.invalidStatus("订单状态非法，无法发货", e)，强调业务含义
- Controller 层统一拦截 OrderException，提取 errorCode 和 httpStatus，返回标准 JSON（如 { "code": "ORDER_003", "msg": "订单状态非法" }）
这样，每层都只抛出自己语义层级的异常，原始 SQLException 始终保留在 getCause() 链底，既没丢失根因，又没污染上层接口。
二、避免“断链”：三类常见异常链破坏行为
异常链失效往往不是技术不会用，而是设计疏忽。以下操作会主动切断链路：
- 用 message 拼接代替嵌套：throw new ServiceException("查询失败：" + e.getMessage()) —— 原始堆栈和类型全丢
- 捕获后仅 log 并 swallow：catch (IOException e) { log.warn("忽略IO异常"); } —— 上层永远收不到信号
- 构造新异常时未传 cause：new BusinessException("参数错误") —— 看似干净，实则丢掉调试关键线索
只要涉及“捕获后再抛”，必须显式传递 cause；若需补充信息，优先用带 cause 的构造器，而非字符串拼接。
三、网关/边界层用异常链做“流量筛子”
在微服务入口（如 Spring Cloud Gateway 或 API 网关 Filter），可借助异常链实现轻量防御：
- 请求头缺失 → 抛 AuthException.missingToken()，不带 cause（纯业务拒绝）
- JSON 解析失败 → 抛 BadRequestException.invalidJson(e)，cause 是 JsonProcessingException
- 下游服务超时 → 抛 RemoteCallException.timeout("user-service", e)，cause 是 FeignException 或 TimeoutException
这些异常统一由全局异常处理器捕获，根据是否含 cause、errorCode 类型、httpStatus 字段，决定返回 4xx（客户端问题）、5xx（服务端问题）或触发熔断降级。异常链在此处成为决策依据，而非日志装饰。
四、日志与监控中善用异常链追溯
单靠日志打印 printStackTrace() 不足以支撑线上排查。应结合异常链做结构化增强：
- 所有自定义异常基类重写 toString()，自动拼接 errorCode + rootCause.getClass().getSimpleName()
- SLF4J 日志输出时，用 MDC 注入 traceId，并在 catch 块中记录：log.error("订单创建失败[trace:{}]", traceId, e)
- 监控系统（如 SkyWalking）采集异常时，不仅上报当前异常类，还递归 getCause() 直到 null，绘制“异常传播图谱”
这样，一个“库存扣减失败”的告警，能直接定位到是 Redis 连接超时（cause），还是 Lua 脚本语法错误（cause 的 cause），而不是卡在中间层的模糊提示。
异常链本身很简单，但把它嵌进分层职责里，就成了系统稳定性的隐形骨架。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
