java - 确定编译时多捕获异常类型

Question

我构建了一些我并不真正理解的东西 - 我不知道它是如何工作的。我已经熟悉了这个 multicatch explaination article .

考虑这两个异常和代码:

public class MyException1 extends Exception {
  // constructors, etc
  String getCustomValue();
}

public class MyException2 extends Exception {
  // constructors, etc
  String getCustomValue() { return "foo"; }
}

try {
  //...
} catch (MyException1|MyException2 e) {
  e.getCustomValue(); // won't work, as I expected
}

我将无法调用 getCustomValue()，即使方法相同，因为在 Java 内部，上面的 try/catch 实际上应该是将 MyException1/2 转换为 Exception(这就是我对文档的理解)。

但是，如果我引入这样的接口(interface):

public interface CustomValueGetter {
  String getCustomValue();
}

public class MyException1 extends Exception implements CustomValueGetter /*...*/
public class MyException2 extends Exception implements CustomValueGetter /*...*/

并将其添加到两个异常中，Java 实际上能够让我使用该方法。然后调用这个是有效的:

try {
  //...
} catch (MyException1|MyException2 e) {
  e.getCustomValue(); // does work
}

简而言之，我的问题是:这里实际发生了什么:(MyException1|MyException2 e)。

什么是e？

• 是否选择了最接近的父类(super class)作为e 的类型？ This question asks about it据推测，这就是答案。如果是这样，那么为什么当我访问 e 时接口(interface) CustomValueGetter 是“可见的”？就我而言，如果 e 是一个 Exception，则不应如此。

• 如果不是，如果真正的类是 MyException1 或 MyException2 为什么我不能简单地调用可用于这两个类的相同方法?

• e 是一个动态生成的类的实例，它实现了两个异常的所有公共(public)接口(interface)并且是最近的公共(public)父类(super class)类型吗？

Answer 1

正如 Ischuetze 所说，e 正在寻找两个异常共享的类或接口(interface)。在您的第一个示例中，尽管有 Exception 类，但找不到共享类，因此它只能使用它提供的方法。

把你的例子改成这段代码就可以再次编译了。

public class MyException12 extends Exception {
    public String getCustomValue(){ return "boo"; };
}

public class MyException1 extends MyException12{
    public String getCustomValue() { return "foo"; };
}

public class MyException2 extends MyException12{
    // constructors, etc
    public String getCustomValue() { return "foo"; };
}

在您的接口(interface)示例中，异常通知 MyException1 和 MyException2 都具有 MyException12，因此能够使用它'函数。

Here是一个 SO 问题，回答了整个问题以及 e 的类型。

引用答案中的链接:

Changing the handling of exception types affects the type system in two ways: in addition to the usual type checking performed on all types, exception types undergo an additional compile time analysis. For the purpose of type checking, a catch parameter declared with a disjunction has type lub(t1, t2, ...) (JLSv3 §15.12.2.7) where the ti are the exception types the catch clause is declared to handle. Informally, the lub (least upper bound) is the most specific supertype of the types in question. In the case of a multi-catch exception parameter, the least upper bound of the types in question always exists since the types of all the caught exceptions must be subclasses of Throwable. Therefore, Throwable is an upper bound of the types in question, but it may not be the least upper bound since some subclass of Throwable may be a superclass (and thereby also a supertype) of the types in question and the exception types in question may implement a common interface. (A lub can be an intersection type of a superclass and one or more interfaces.) For the purpose of exception checking (JLSv3 §11.2), a throw statement (JLSv3 §11.2.2) that rethrows a final or effectively final catch parameter is treated as throwing precisely those exception types that: