根本原因在于泛型的类型擦除机制与JVM异常处理机制不兼容：擦除后所有MyException均变为MyException，导致catch无法区分具体类型，且编译器无法在throws中验证动态类型T是否为合法异常子类。
Java 不允许定义泛型异常类，比如 class MyException<t> extends Exception</t>，根本原因在于**泛型的类型擦除机制与 JVM 异常处理机制不兼容**。
类型擦除让 catch 无法工作
JVM 在运行时捕获异常，依赖的是精确的、可识别的类类型。而泛型类在编译后会被擦除为原始类型（如 MyException<t></t> → MyException），所有类型参数信息（T）全部丢失。这意味着：
- 你无法写出合法的
catch (MyException<string> e)</string>—— 编译器直接报错，因为该语法不被支持； - 即使绕过编译（如用反射构造带泛型的异常实例），JVM 在匹配
catch块时也只认类名和继承关系，完全看不到<string></string>这部分； - 异常处理链条失去类型语义，
catch (MyException<integer>)</integer>和catch (MyException<ioexception>)</ioexception>在运行时根本无法区分。
Throwable 体系要求编译期确定性
Java 的异常检查是编译期强制的：受检异常必须被声明（throws）或捕获（try-catch）。这种强制约束依赖于异常类型在编译时就完全明确。而泛型类型参数 T 是动态占位符，不是具体类，编译器无法验证：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
T是否是Exception或其子类（哪怕写了<t extends exception></t>，擦除后也无法保证）； - 抛出
new MyException<nullpointerexception>()</nullpointerexception>后，调用方该用哪个catch块？编译器无从推断。
替代方案：用字段携带类型化数据
若需传递类型化的错误上下文（如错误码、详情对象），应避免泛型继承，改用普通异常类封装泛型字段：
立即学习“Java免费学习笔记（深入）”；
- 定义
class TypedException extends Exception； - 内部用
private final Object detail存储任意对象； - 提供
@SuppressWarnings("unchecked") public <t> T getDetail()</t>方法做安全转换； - 调用方按需转成所需类型，例如
exception.getDetail()得到ErrorResponse实例。
为什么 throws 里也不能写泛型类型
同理，方法签名中 throws T 是非法的。因为 throws 子句参与编译期异常检查，而 T 在擦除后不存在，JVM 无法在运行时验证实际抛出的是否真属于那个“已消失”的类型。常见错误提示包括：illegal generic type for throws clause 或 IDE 整行标红。
