Java禁止泛型类继承Throwable，因类型擦除导致运行时无法区分不同参数化异常类，使catch机制失效；同样禁止catch中使用类型参数T，因JVM需确定类类型匹配；但允许throws中用类型参数、类型限定继承Throwable，以及用具体异常类携带泛型数据。
泛型类不能继承 Throwable 的根本原因
Java 不允许定义形如 class MyExceptionMyException<integer></integer> 和 MyException<string></string> 都变成 MyException）。而异常处理机制依赖精确的、可区分的类类型：catch 块靠 JVM 在运行时匹配异常对象的实际类名。如果允许泛型异常，多个不同参数化的子类在运行时无法区分，会导致 catch 分支歧义甚至不可预测的行为。
为什么 catch 中不能用类型参数
你不能写这样的代码：
public static <T extends Exception> void handle(List<?> jobs) {
try { /* ... */ }
catch (T e) { // 编译错误：Cannot use the type parameter T in a catch block
}
}原因和上一条一致：catch 子句需要一个确定的、可加载的类类型，而 T 是编译期占位符，运行时不存在。JVM 没法根据一个擦除后的类型去查找并实例化对应的异常处理器。所以 Java 明确禁止在 catch 中使用类型变量。
哪些操作是合法且实用的
虽然不能让泛型类继承 Throwable，也不允许 catch 类型参数，但 Java 仍提供了灵活的泛型异常支持方式：
-
throws 子句中可以使用类型参数：例如
public <E extends Exception> void doWork() throws E是完全合法的，它把异常类型约束前移至方法签名，调用方需明确传入具体异常类型（如Failure1），编译器据此生成正确的 throws 检查。 -
泛型类型限定可继承 Throwable：像
class Processor<T, E extends Throwable>是允许的，这里E是对类型参数的上界约束，并非泛型类自身继承 Throwable，不触发擦除冲突。 -
用具体异常类组合泛型逻辑：推荐做法是定义非泛型的具体异常（如
ValidationException），再通过字段携带泛型数据（如private final List<String> errors），既保持类型安全，又兼容异常机制。
绕不开的实践提醒
不要试图用泛型异常实现“一类异常适配多种上下文”的设计。Java 的异常体系建立在静态可识别性之上，而泛型的本质是编译期抽象，二者底层模型冲突。真正需要差异化处理的场景，应通过异常的继承层次（如 NetworkException / TimeoutException）、状态字段或策略模式解耦，而不是依赖泛型参数。
