java异常二次抛出与上下文封装的核心是不掩盖问题、不丢失线索、不破坏职责；应将技术异常封装为业务异常并保留cause链，禁止重复包装、吞异常或丢弃堆栈。
Java中异常的二次抛出与上下文封装，核心是“不掩盖问题、不丢失线索、不破坏职责”。捕获后直接 throw e; 是最简方式，但往往不够；真正实用的做法，是在抛出前把原始异常包进一个更有业务含义的新异常里，同时保留堆栈和原因链。
什么时候必须二次抛出
当前层无法独立完成错误恢复或决策时，就该把异常交上去。比如：
- DAO 层执行 SQL 失败，它不知道该返回空列表还是报错提示用户，应抛给 Service 层统一处理
- 远程调用超时，但本层没做重试或降级，只记录日志后静默吞掉，会导致上层误以为成功
- 方法签名已声明 throws IOException，却在 catch 里只打印 stackTrace() 就结束，违反契约，调用方无法响应失败
如何正确封装再抛出
关键不是换名字，而是换视角——把技术异常转成业务语言，并确保原始信息不丢。推荐做法：
- 用自定义异常类（如 ServiceException、OrderException），继承 Exception（受检）或 RuntimeException（非受检），根据是否强制调用方处理来选
- 构造时始终传入原始异常作为 cause：new ServiceException("下单失败", e)，而不是 new ServiceException("下单失败").initCause(e)
- 消息里可加入运行时上下文，比如订单ID、用户ID、时间戳，但不要拼接 e.getMessage()，避免重复或泄露敏感信息
哪些操作要避免
看似合理，实则埋雷的做法包括：
- 多层重复包装：A 层 catch SQLException → 包成 ServiceException；B 层又 catch ServiceException → 包成 BusinessException，堆栈变长且语义模糊
- 吞异常只写 e.printStackTrace()：没有日志级别、无监控上报、调用方收不到信号，系统可能持续出错而不报警
- 用无参构造器新建异常再 throw，导致 getCause() 为 null，Spring 等框架无法按异常类型分类拦截
配合 throws 声明使用
只要方法体中明确抛出了受检异常（即继承自 Exception 的非 RuntimeException 子类），就必须在方法签名中加 throws。这不是形式主义，而是接口契约：
- 让调用方在编译期就知道可能遇到什么异常，决定是 try-catch 还是继续向上声明
- 便于统一接入全局异常处理器（如 Spring 的 @ControllerAdvice）
- 避免因遗漏 throws 导致编译失败，或临时改成 RuntimeException 绕过检查，破坏异常设计初衷
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
