本文介绍如何通过 Supplier

本文介绍如何通过 `supplier extends exception>` 替代 `class extends exception>`，安全、简洁地将任意自定义异常延迟实例化并抛出，避免反射带来的复杂性与运行时风险。

在 Java 开发中，当多个数据访问层（如 UserRepo、OrderRepo 等）各自抛出不同但同源的自定义异常（例如 UserNotFoundException、OrderValidationException），而你希望将异常抛出逻辑统一收口至上层控制器（Controller）时，直接传递异常类类型（Class）看似合理，实则存在根本性限制：orElseThrow() 接收的是 Supplier extends X>，而非 Class 对象；仅凭 Class 无法自动构造异常实例，必须借助反射——这不仅冗长易错，还可能因无参构造器缺失、访问权限或异常链中断而失败。

✅ 推荐方案：使用 Supplier extends Exception>
该函数式接口天然契合“延迟创建+按需抛出”的语义，既保持类型安全，又完全规避反射。控制器方法可定义为：

public <T> T generic(String input, Supplier<? extends Exception> exceptionSupplier) throws Exception {
    return call(input).orElseThrow(exceptionSupplier);
}

调用方则直接传入带上下文的异常构造逻辑，例如：

// 抛出 UserNotFoundException
generic("u123", () -> new UserNotFoundException("用户 ID u123 不存在"));

// 抛出 OrderValidationException（含参数校验细节）
generic("order-789", () -> new OrderValidationException("订单 order-789 金额超限：¥100,000 > ¥50,000"));

⚠️ 注意事项：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• Supplier 中的异常构造必须是无副作用的纯逻辑（不修改状态、不触发 I/O）；
• 若异常需依赖运行时变量（如 input 值），应在 lambda 内直接引用（Java 闭包天然支持）；
• 方法声明 throws Exception 虽兼容所有子类，但建议在实际使用中显式声明更具体的异常类型（如 throws UserNotFoundException, OrderValidationException），以提升 API 可读性与编译期检查能力；
• 避免在 Supplier 中抛出非 Exception 的 RuntimeException——orElseThrow 会原样传播，但可能破坏 throws 声明的一致性。

? 总结：将异常创建权交给调用方，通过 Supplier 实现“策略注入”，是比反射更轻量、更健壮、更符合函数式编程思想的设计。它让控制器真正成为协调者，而非异常工厂，显著提升代码可维护性与可测试性。

立即学习“Java免费学习笔记（深入）”；