SQLException是受检异常，需分层归责转换为业务异常、语义升维包装、全局兜底处理，并可用Optional/Result封装避免异常控制流程。
SQLException 是受检异常（checked exception），必须显式处理，不能忽略。但直接层层 throws 或 try-catch 吞掉都容易导致错误信息丢失、事务失控或调用方无法感知失败。优雅传递的关键是：**分层归责、语义升维、统一兜底**。
按职责分层，让 DAO 层只抛数据访问语义异常
DAO 方法不应把 SQLException 直接暴露给 service 层。应在 DAO 内部捕获，转换为更抽象、业务友好的运行时异常（如自定义 DataAccessException），同时保留原始 SQLException 作为 cause：
- 避免在 service 层写大量 SQLException 的 instanceof 判断
- 保留堆栈和 SQL 状态码（getSQLState()）、错误码（getErrorCode()）等关键信息
- 示例：throw new DataAccessException("查询用户失败", e);
在 service 层做语义增强，不掩盖上下文
service 层若需进一步封装（比如区分“库存不足”和“数据库连接超时”），可捕获上层异常，包装成带业务语义的异常（如 InventoryException、SystemUnavailableException），但仍应链式保留原始 SQLException：
- 不要只 throw new XxxException("操作失败") —— 会丢失根源
- 推荐写法：throw new InventoryException("扣减库存失败", dataAccessException);
- 这样日志可追溯完整链路，监控也能按 cause 类型聚合告警
全局异常处理器统一降级与响应
在 Web 层（如 Spring MVC 的 @ControllerAdvice）集中拦截异常链中最外层的业务异常，提取 SQLException 信息做差异化处理：
立即学习“Java免费学习笔记（深入）”；
- SQLState 以 "08" 开头（连接类）→ 返回 503 Service Unavailable
- SQLState 以 "23" 开头（约束违规）→ 转为 400 并附具体字段提示
- 其他情况 → 记录完整异常链日志，返回通用错误码，不暴露数据库细节
必要时用 Optional 或 Result 封装，避免异常控制流程
对非关键、预期可能失败的操作（如根据 ID 查询缓存未命中后查 DB），可考虑返回 Optional<User> 或自定义 Result<User>，将“查不到”视为正常流程分支，而非异常场景。SQLException 仍需捕获并转为失败 Result，但不再向上抛出。
这样既规避了受检异常的强制传播负担，又让调用方清晰区分“业务不存在”和“系统不可用”。
