为什么 Java 不支持泛型 Throwables？

Question

class Bouncy<T> extends Throwable {     
}
// Error: the generic class Bouncy<T> may not subclass java.lang.Throwable

为什么 Java 不支持泛型 Throwables？

我意识到类型擦除会使某些事情复杂化，但显然 Java 已经完成了很多工作，那么为什么不将其推高一个档次并允许泛型 Throwables，并通过全面的编译时检查潜在问题？

---

我觉得类型擦除参数相当弱。目前，我们不能这样做：

void process(List<String> list) {
}

void process(List<Integer> list) {
}

当然，没有它我们也能过得去。我不是要求我们应该能够在同一个 try 块中执行 catch Bouncy<T1> 和 Bouncy<T2>，但是如果我们在具有严格编译时可执行规则的不相交上下文中使用它们（这几乎是泛型的方式现在可以使用），它不可行吗？

Answer 1

Java 语言规范 8.1.2 Generic Classes and Type Parameters:

这个限制是必要的，因为 Java 虚拟机的 catch 机制只适用于非泛型类。

就个人而言，我认为这是因为我们无法在catch 子句中获得泛型的任何好处。由于类型擦除，我们不能写catch (Bouncy<String> ex)，但是如果我们写catch (Bouncy ex)，让它泛型就没用了。

Answer 2

类型擦除。运行时异常类型没有泛型信息。所以你做不到

} catch( Mistake<Account> ea) {
  ...
} catch( Mistake<User> eu) {
...
}

你能做的就是

catch( Mistake ea ) {
  ...
}

类型擦除是在 Java 从 1.4 迁移到 1.5 时决定保留向后兼容性的方式。许多人当时不高兴，这是理所当然的。但是考虑到部署代码的数量，破坏在 1.4 中运行良好的代码是不可想象的。

Answer 3

以下是您可以做的几件事：

1. Throwables 可以实现泛型接口，只要 throwable 本身没有类型参数，例如
   

   interface Bouncy<E> {
    // ...
}
class BouncyString extends Exception implements Bouncy<String> {
    // ...
}

2. throws 子句可以引用类型参数，例如

   static <X extends Throwable> void
throwIfInstanceOf(Throwable ex, Class<X> clazz) throws X {
    if (clazz.isInstance(ex)) throw clazz.cast(ex);
}

Answer 4

简短的回答：因为他们走捷径，就像他们使用擦除一样。

长答案：正如其他人已经指出的那样，由于擦除，在运行时无法区分“catch MyException”和“catch MyException”。

但是这并不意味着不需要通用例外。我希望泛型能够使用泛型字段！他们本可以简单地允许通用异常，但只允许在原始状态下捕获它们（例如“catch MyException”）。

当然，这会使泛型变得更加复杂。 这是为了表明删除仿制药的决定是多么糟糕。我们什么时候会有支持真正泛型（使用 RTTI）而不是当前语法糖的 Java 版本？

Answer 5

您仍然可以使用泛型方法，如下所示：

public class SomeException {
    private final Object target;

    public SomeException(Object target) {
        this.target = target;
    }

    public <T> T getTarget() {
        return (T) target;
    }
}

....

catch (SomeException e) {
    Integer target = e.getTarget();
}

我同意克里斯蒂安的上述回答。虽然公认的答案在技术上是正确的（就其引用 JVM 规范而言），但 Cristian Vasile 的答案是符合甚至挑战限制的答案。

我在回答这个问题时指出了至少两个我不同意并且我将反驳的论点。如果这些答案中的论点是正确的，我们可以使用这些论点在今天成功使用它们的其他上下文中攻击泛型。

---

第一个参数声明我们不能使用这个：

catch (Exception<T1> e) {}

因为 JVM 不知道如何使用 Exception<T1>。这个论点似乎也在攻击泛型的这种使用，因为 JVM 不知道如何使用List<T1>：

List<T1> list;

当然，该参数忘记了编译器执行类型擦除，因此 JVM 不需要知道如何处理 Exception<T1>。它可以简单地处理Exception，就像它处理List一样。

当然，由于类型擦除，我们永远无法在同一个 try/catch 中处理 catch(Exception<T1> e) 和 catch(Exception<T2> e)，但话又说回来，这并不比今天使用方法参数或返回值更糟糕：我们不处理 @ 987654331@ 和 myMethod(List<T2>) 今天也可以……（我在下面的第二次反驳中重申了这一点。）

---

第二个参数如下。我们不允许这样做：

catch (Exception<T1> e) {}

因为这行不通：

catch (Exception<T1> e) {}
catch (Exception<T2> e) {}

好的，那为什么不禁止这个：

interface MyInterface {
    Comparable<Integer> getComparable();
}

因为这不起作用：

interface MyInterface {
    Comparable<Integer> getComparable();
    Comparable<String> getComparable();
}

或者这个：

interface MyInterface {
    void setComparable(Comparable<Integer> comparable);
}

因为这不起作用：

interface MyInterface {
    void setComparable(Comparable<Integer> comparable);
    void setComparable(Comparable<String> comparable);
}

换句话说，为什么在大多数情况下不禁止泛型？

第二个论点忘记了，尽管我们不可能允许在这些上下文中擦除到相同非泛型构造的不同泛型构造，但我们仍然可以做次优的事情，并且允许泛型只要类型不会擦除为相同的类型。这就是我们对方法参数所做的事情：我们允许您使用泛型，但一旦我们在类型擦除后检测到重复签名就会抱怨。好吧，我们可以用异常和 catch 块做同样的事情......

---

最后，我将扩展 Cristian 的答案。而不是允许通用异常类和使用catch块中的原始类型：

class MyException<T> {}
...
catch (MyException e) { // raw

Java 完全可以毫无问题地完成：

class MyException<T> {}
...
catch (MyException<Foo> e) {