Java无法直接用泛型类型捕获异常，因泛型擦除导致JVM运行时无法区分不同参数化的泛型异常类，且泛型类不能继承Throwable，catch块中也不允许使用类型参数；合法替代方案包括泛型throws声明、异常内含泛型字段或异常包装器模式。
Java 中无法直接用泛型类型捕获异常，这是语言层面的硬性限制，不是写法或技巧问题。根本原因在于 JVM 的异常匹配机制依赖运行时可识别的具体类名，而泛型在编译后会被擦除，导致不同参数化的泛型异常（如 MyException<String> 和 MyException<Integer>）在运行时都变成同一个原始类 MyException，JVM 无法区分，catch 分支就会失效。
泛型类不能继承 Throwable
你不能定义这样的类：
-
class MyException<T> extends Exception→ 编译直接报错 -
class ValidationFailure<E> extends RuntimeException→ 同样不被允许
因为 Throwable 及其子类必须是具体、可加载的类型。泛型类作为异常类型会破坏 JVM 异常分发的确定性——它无法保证 catch (MyException<String> e) 和 catch (MyException<Integer> e) 是两个独立分支。
catch 块中不能使用类型参数
下面这段代码是非法的：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
public <T extends Exception> void handle() { try { ... } catch (T e) { ... } }→ 编译失败：“Cannot use the type parameter T in a catch block”
原因同上：T 是编译期占位符，运行时不存在对应类对象，JVM 没法完成类型匹配。哪怕你传入了 IOException.class，catch(T) 仍不可行。
合法且实用的替代方案
虽然不能“泛型化异常本身”，但可以通过组合方式实现类似效果：
-
在 throws 中使用类型参数：方法签名可以声明泛型异常，调用方需明确传入具体异常类型，编译器据此做检查。
public <E extends Exception> void doWork() throws E -
用类型限定约束异常参数：泛型类可接受一个上界为
Throwable的类型参数，用于携带异常逻辑，但自身不继承它。class Processor<T, E extends Throwable> -
用具体异常类封装泛型数据：定义非泛型异常（如
ValidationException），内部用泛型字段存上下文信息。private final List<String> errors;或private final Map<String, Object> details; -
异常包装器模式：统一抛出一个运行时包装异常（如
WrappedException），把原始异常设为 cause，再在catch中用instanceof判断 cause 类型并处理。
实际编码建议
不要试图绕过限制去“模拟泛型异常捕获”。更务实的做法是：
- 按业务语义定义清晰的、具体的异常子类（如
NetworkTimeoutException、JsonParseException） - 用泛型方法或泛型容器传递异常相关数据（比如错误码列表、校验失败字段），而非让异常本身泛型化
- 在日志或监控中补充泛型上下文（如操作的泛型类型名、参数类型），提升排查效率
Java 的异常体系设计优先保障运行时行为可预测，泛型则侧重编译期类型安全——两者目标不同，强行融合反而增加复杂度。用对的方式，比“看起来像泛型”更重要。
