Java泛型不能用于throws子句，因类型擦除导致JVM无法在运行时验证异常类型；虽可用Class参数+反射或RuntimeException包装模拟，但均牺牲编译期安全。
Java 泛型不能用在 throws 子句里
Java 不允许在方法签名的 throws 部分使用类型参数，比如写成 void foo() throws T 是编译错误。这是因为异常类型必须在编译期完全确定，而泛型类型参数会在类型擦除后消失，JVM 无法在运行时验证 throw 的实例是否真属于那个“擦除后不存在”的泛型类型。
常见错误现象：error: unexpected type 或 illegal generic type for throws clause；IDE 通常会直接标红整行 throws T。
- 泛型只适用于类、接口、方法体内部（如返回值、参数、局部变量），不适用于
throws - 哪怕
T extends Exception，也不能绕过这个限制——擦除机制不为异常检查留例外 - 想“模拟”泛型异常？得靠运行时类型检查 + 显式
throw new RuntimeException(...)包装，但这就失去了编译期异常安全
替代方案：用泛型方法封装受检异常的抛出逻辑
虽然不能把 T 放在 throws 里，但可以借助泛型方法 + Class<t></t> 参数 + 反射，在运行时构造并抛出指定类型的异常。前提是该异常是受检异常，且你愿意承担反射带来的可读性与性能成本。
典型使用场景：统一异常转换框架、测试中模拟不同异常分支、DSL 式 API 设计。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 必须传入
Class<t></t>，因为泛型信息已擦除，没它就无法实例化 - 需要处理
InstantiationException和IllegalAccessException这两个必然出现的底层异常 - 若
T是抽象类或接口，反射会失败——必须是可实例化的具体异常子类 - 示例：
static <T extends Exception> void throwChecked(Class<T> exType) throws Exception { throw exType.getDeclaredConstructor().newInstance(); }
RuntimeException 子类可以“假装”泛型，但只是语法糖
有些库（如 Vavr、自定义工具类）提供类似 throw new SneakyThrow<ioexception>()</ioexception> 的写法，本质是继承 RuntimeException 并带一个泛型字段，再配合 @SuppressWarnings("unchecked") 把检查异常“转成”运行时异常抛出。它不改变 Java 的语法限制，只是绕过编译器校验。
关键点在于：这不是真正的泛型异常抛出，而是放弃编译期异常检查的权衡。
- 调用方不会被强制处理该异常，
try-catch或throws声明都非必需 - 所有此类技巧都会让 IDE 和静态分析工具失效，容易遗漏异常处理路径
- 如果异常本应是受检的（比如
IOException），用这种方式隐藏它，可能掩盖资源泄漏或状态不一致问题
最容易被忽略的坑：泛型异常捕获本身没问题，但别混淆声明和捕获
你可以用泛型变量接收捕获的异常（如 T e = (T) caught;），也可以写泛型方法来统一处理异常（<t extends throwable> void handle(T e)</t>），这些都没问题。问题出在“声明要抛出什么”这个环节——那是唯一被语言硬性禁止泛型的地方。
很多人调试时卡在“为什么 catch (T e) 报错”，其实那不是泛型限制，而是 Java 语法根本不允许 catch 参数用类型变量；正确写法永远是 catch (Exception e) 再做 instanceof 判断。
-
catch块不支持类型参数，这是独立于throws的另一条限制 - 泛型方法里
throw new Exception()后，调用方看到的仍是擦除后的异常类型，不是你期望的T - 真正安全的泛型异常交互，只存在于“捕获 → 判断 → 转发”链条中，且转发必须用具体类型
