问题的历史： 当Java 5引入泛型，通过类型擦除来保持与预泛型字节码的二进制兼容性时，语言设计者维持了在Java 1.0中建立的现有JVM异常处理架构。class文件格式通过Code属性中的exception_table数组表示异常处理程序，该数组存储常量池索引，指向每种可捕获异常类型的具体CONSTANT_Class_info结构。这一设计选择优先考虑运行时性能和验证简单性，而非异常处理的泛型多态性。
问题： 由于泛型类型参数在编译时被擦除到它们的边界（通常是Object），因此在运行时没有唯一的Class文字来填充exception_table条目。JVM字节码验证器要求静态解析的类引用，以便在执行开始之前构造异常处理程序调度表，确保类型安全的控制流转移。一个泛型捕获参数catch (T e)将要求运行时匹配未解析的类型变量，这违反了JVM规范中异常处理程序必须引用具体的、可加载的类及其明确的类层次元数据的要求。
解决方案： 编译器通过在编译时拒绝泛型捕获参数来强制执行这一限制，迫使开发者捕获被擦除的边界（通常是Exception或Throwable），并使用instanceof检查和显式类型转换。或者，异常转换模式将受检异常封装在特定领域的运行时异常中，通过构造函数保留原始原因。这些方法在保持静态exception_table完整性的同时，允许通过动态类型检查或结果单子进行特定类型的处理逻辑，而不是捕获子句参数化。
一个分布式任务执行框架需要一个泛型Task<T extends Exception>接口，实施者可以声明特定的失败模式。最初的设计尝试使用try { task.execute(); } catch (T failure) { handler.handle(failure); }来实现错误处理策略的编译时类型安全，但由于泛型捕获限制而失败编译。
考虑的第一个解决方案是为每种异常类型实现重载包装类（例如，IOExceptionTask、SQLExceptionTask）。这种方法提供了编译时类型安全和每个失败模式的不同方法签名，但随着系统的扩展，遭遇了组合爆炸。它迫使开发者创建样板子类单纯为了满足类型约束，增加了维护负担并违反了DRY原则。
第二个解决方案提议捕获Throwable并在处理程序中根据instanceof验证后执行未经检查的类型转换。虽然这通过调用点的反射处理了泛型类型参数，但它引入了显著的运行时开销，特别是针对期望错误条件的异常实例化（具体来说是fillInStackTrace成本）。它也牺牲了彻底性检查，可能通过无意中捕获Error类型或共享擦除超类的意外受检异常来掩盖编程错误。
所选解决方案采用了异常转换策略，并结合了Result<T, E>单子模式。任务不再直接抛出异常，而是返回包含成功值或使用密封类层次结构的类型错误的Result对象。这完全消除了泛型捕获子句的需要，将错误处理移动到值域，在该域中泛型工作完好无损，并通过泛型返回类型而非异常签名保持类型安全。该框架实现了40%的样板代码减少，消除了在错误处理期间发生ClassCastException的风险，并通过避免为预期错误条件创建异常对象来提高性能。
为什么方法签名可以声明throws T，而T extends Throwable，但catch子句不能使用相同的类型参数？
JVM允许泛型throws子句，因为class文件格式中的Exceptions属性存储擦除类型（通常是Throwable），以供字节码验证，而泛型签名则在Signature属性中为反射元数据保留。运行时验证器检查擦除类型，而编译器通过静态分析强制T绑定到有效异常类型，而不影响调用点。相反，catch子句要求在exception_table中有条目，该条目将特定程序计数器范围映射到使用具体Class池索引的处理程序偏移量，这些索引必须在链接期间解析为加载类。由于类型变量缺乏运行时类元数据，并且可能在不同的调用点绑定到不同的类型，JVM无法构造执行异常处理所需的静态调度映射，从而使泛型捕获子句在架构上变得不可能，无论throws子句的灵活性如何。
如果允许捕获泛型异常，类型擦除与受检异常机制之间的交互如何引发微妙的验证风险？
如果允许泛型捕获，则代码如catch (T e)，其中T在一个调用点绑定到IOException，并在另一个绑定到SQLException，在源代码级别看似是类型安全的。但由于类型擦除，JVM会将两者视为捕获Exception（被擦除的上界）。这将允许捕获意外的受检异常，这些异常与同一擦除的超类共享，违反了Java语言规范中关于受检异常捕获的规定。验证器确保捕获块仅处理可抛出的子类，但擦除会将不同的受检异常类型折叠成同一处理程序，可能会使SecurityException或其他运行时异常被捕获和处理，仿佛它们是声明的受检类型，导致特权升级漏洞或静默错误吞噬。
编译器在使用instanceof检查模拟类型特定捕获行为时生成的特定字节码模式是什么，以及与原生异常表调度相比会出现什么性能影响？
当开发者编写catch (Exception e) { if (e instanceof SpecificType) { handle(e); } else { throw e; } }时，编译器为Exception生成一个exception_table条目，接着在处理程序块中生成checkcast或instanceof字节码指令。这会创建一个两阶段调度：首先，JVM捕获广义类型（实例化异常对象并通过fillInStackTrace捕获完整堆栈跟踪），然后用户代码进行过滤。性能影响包括即使是在过滤异常时也要进行异常对象分配的开销，以及来自instanceof检查的额外分支错误预测成本。这与原生异常表调度形成对比，后者利用JVM的内部处理程序缓存实现O(1)类型匹配，而不实例化过滤的异常对象，使得在高频异常场景下，instanceof方法的性能较慢几个数量级。