java 不允许 catch (t e)，因为泛型类型参数 t 在编译后被擦除，jvm 运行时无法识别其具体类型，且编译器无法验证 t 是否继承 throwable 或生成异常表条目。
因为 JVM 在运行时根本认不出 T 是什么类型。
catch 要求具体、可加载的类类型
Java 的异常捕获机制依赖编译后的真实类信息。而泛型类型参数 T 只是编译期占位符，经过类型擦除后，所有泛型信息都消失了。JVM 运行时看到的只有原始类型（比如 Exception），没有 T 对应的具体类名和字节码。所以 catch (T e) 编译直接报错——语法不被允许。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
类型擦除让运行时无法区分泛型异常
- 假设写了
class MyException<t> extends Exception</t>，编译后全变成MyException -
catch (MyException<string> e)</string>和catch (MyException<integer> e)</integer>在字节码里完全一样 - JVM 捕获异常时只按类名+继承链匹配，
<string></string>这部分信息早已丢失
替代方案：用 throws + 上界约束更安全
虽然不能 catch (T e)，但 Java 允许在方法声明中使用泛型异常：
-
<e extends throwable> void doWork() throws E</e>—— 合法，调用时必须指定具体异常类型 -
class Processor<t e extends throwable></t>—— 泛型参数E限定为异常类型，只是约束，不涉及实例化
根本矛盾在于编译期检查与运行时机制的断层
Java 异常处理是编译期强制的：受检异常必须显式声明或捕获。而 T 不是确定类，编译器无法验证它是否继承自 Throwable，也无法生成对应的异常表条目。这种静态语义要求和泛型动态占位的本质冲突，决定了 catch (T e) 永远不会被支持。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
