Java多层调用中正确传递受检异常的核心是控制传播路径、明确责任归属、避免契约污染：必须显式throws声明，合理转换为语义化业务异常，保留cause链，并依分层职责决定透传或拦截。
Java 中多层调用里正确传递受检异常，核心不是“原样甩上去”，而是有意识地控制传播路径、明确责任归属、避免污染上层契约。关键在于：该声明时就声明，该转换时就转换，不该暴露的绝不裸露。
必须在方法签名中用 throws 显式声明
受检异常（如 IOException、SQLException）一旦出现在方法体中且未被 catch，就必须在方法头用 throws 声明，否则编译失败。这是 Java 的强制约束，也是清晰表达“我可能出问题”的第一道防线。- 一个方法调用了 FileInputStream 构造器 → 必须 throws FileNotFoundException
- Service 方法调用了 JDBC 查询 → 可声明 throws DataAccessException（自定义受检异常），而不是直接抛 SQLException
- 多个异常可并列声明：
public void process() throws IOException, InterruptedException
不声明也不捕获，代码根本过不了编译。这不是限制，而是提醒你：这个错误，调用方得知道、得准备。
不要在中间层静默吞掉或随意包装
常见错误是：DAO 层 catch 了 SQLException，只打日志却不 throw；或者转成 new RuntimeException("db error")，但没带原始异常作为 cause。- ✅ 正确做法：在 DAO 或 Service 关键转化点，用语义化方式包装并继续抛出
例如：throw new OrderProcessingException("库存扣减失败", e); - ❌ 错误做法：
-
catch (SQLException e) { log.warn("ignored", e); }→ 异常消失，逻辑中断却无感知 -
throw new RuntimeException("DB failed");→ 堆栈丢失，根因不可查
-
保留 cause 是底线。用带 Throwable 参数的构造函数，确保异常链完整。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
根据调用场景决定是否向上透传
不是所有受检异常都适合一路 throws 到 Controller。要结合分层职责判断：- 基础组件层（IO、DB 工具类）：可以抛受检异常，由上层决定重试、降级或转业务异常
- 业务服务层（Service）：建议统一转为自定义受检业务异常（如 InsufficientBalanceException），让 Controller 明确知道“这是业务规则失败”，而非“磁盘坏了”
- 表现层（Controller）：不建议再 throws 受检异常，应统一捕获并转为 HTTP 响应（如 400/500 + JSON 错误码）
如果 Controller 方法签名出现 throws IOException，大概率说明异常边界没划清。
立即学习“Java免费学习笔记（深入）”；
用抽象接口隔离底层异常细节
通过定义不抛底层异常的接口，把实现细节屏蔽掉：- DAO 接口方法声明：
User findById(Long id) throws UserNotFoundException; - 实现类内部处理 SQLException → 包装为 UserNotFoundException 抛出
- Service 层调用该接口时，只面对 UserNotFoundException，无需关心 JDBC 或连接池
这样既满足编译检查，又不让业务逻辑耦合数据访问技术细节。
