Java禁止catch子句使用泛型类型变量，因JVM异常表需确定类名而T无运行时身份，且JLS语法层面直接禁止类型变量作为catch参数。
Java 不允许在 catch 子句中使用泛型类型变量（如 catch (T e)），这不是编译器“不够智能”，而是语言设计和 JVM 运行机制共同决定的硬性限制。
catch 依赖运行时可识别的具体类名
JVM 的异常分发机制完全基于字节码中的异常表（exception table），该表每一项都明确记录了：某段代码范围内，若抛出指定类名（如 IOException）或其子类的异常，就跳转到对应 handler 执行。这个类名必须是编译后真实存在的、能被 JVM 加载的类。
而 T 是一个类型变量，它没有运行时类身份——擦除后可能变成 Exception，也可能变成 Object，甚至尚未绑定。编译器无法为 catch (T e) 生成合法的异常表项，因为目标类名根本不确定。
语法层面直接拒绝，不进入类型擦除流程
Java 语言规范（JLS §14.20）明确规定：catch 参数只能是类类型（ClassType）或带 Throwable 上界的限定类型，**明确排除类型变量（TypeVariable）**。
立即学习“Java免费学习笔记（深入）”；
这意味着解析源码时，编译器在语法树构建阶段就判定 catch (T e) 非法，根本不会让它进入后续的类型检查或擦除环节。它不是语义错误，而是语法禁止（syntactic prohibition）。
与 throws 中使用 T 完全不同
throws T 是合法的，因为 throws 只参与编译期异常检查，不生成字节码中的异常表；编译器只需验证 T extends Throwable 是否成立，并将具体类型传递给调用方。
而 catch 是控制流契约的一部分，必须在运行时精确匹配并接管异常处理。把类型变量引入控制流，会破坏异常处理的确定性和可验证性。
泛型异常类本身也不被允许
同理，class MyException<t> extends Exception</t> 也被禁止。擦除后所有 MyException<string></string>、MyException<integer></integer> 都变成同一个原始类 MyException，JVM 无法区分，catch (MyException<string> e)</string> 语法不合法，且运行时也无法实现类型特异性捕获。
所以问题不在“能不能写”，而在于 JVM 异常机制从底层就不支持泛型参与异常分发逻辑。
