为什么 Java 不允许从静态初始化块中抛出已检查的异常？

Question

为什么 Java 不允许从静态初始化块中抛出已检查的异常？这个设计决定背后的原因是什么？

Answer 1

因为在您的源中不可能处理这些已检查的异常。您对初始化过程没有任何控制权，并且无​​法从源中调用 static{} 块，因此您可以用 try-catch 包围它们。

由于无法处理已检查异常指示的任何错误，因此决定禁止抛出已检查异常静态块。

静态块不得抛出已检查异常，但仍允许抛出未检查/运行时异常。但根据上述原因，你也无法处理这些。

总而言之，此限制阻止（或至少使开发人员更难）构建可能导致应用程序无法恢复的错误的东西。

Answer 2

您可以通过捕获任何已检查异常并将其作为未检查异常重新抛出来解决该问题。这个未经检查的异常类可以很好地用作包装器： java.lang.ExceptionInInitializerError。

示例代码：

protected static class _YieldCurveConfigHelperSingleton {

    public static YieldCurveConfigHelper _staticInstance;

    static {
        try {
            _staticInstance = new YieldCurveConfigHelper();
        }
        catch (IOException | SAXException | JAXBException e) {
            throw new ExceptionInInitializerError(e);
        }
    }
}

Answer 3

它必须看起来像这样（这是不是有效的Java代码），

// Not a valid Java Code
static throws SomeCheckedException {
  throw new SomeCheckedException();
}

但是你会在哪里捕获它呢？检查异常需要捕获。想象一些可能初始化类的示例（或者可能不会，因为它已经初始化了），只是为了引起人们对它所引入的复杂性的注意，我将这些示例放在另一个静态初始化器中：

static {
  try {
     ClassA a = new ClassA();
     Class<ClassB> clazz = Class.forName(ClassB.class);
     String something = ClassC.SOME_STATIC_FIELD;
  } catch (Exception oops) {
     // anybody knows which type might occur?
  }
}

还有另一个令人讨厌的事情 -

interface MyInterface {
  final static ClassA a = new ClassA();
}

想象 ClassA有一个静态初始化程序抛出一个已检查的异常：在这种情况下，MyInterface（这是一个具有“隐藏”静态初始化程序的接口）必须抛出异常或处理它 - 在接口处进行异常处理？最好保持原样。

Answer 4

为什么 Java 不允许从静态初始化块中抛出已检查的异常？

从技术上讲，你可以做到这一点。但是，必须在块内捕获已检查的异常。

实际的 Java 限制是不允许检查的异常传播到块之外。

从技术上讲，还可以允许未检查异常从静态初始化程序块¹传播出去。但故意这样做实在是个坏主意！问题在于 JVM 本身捕获了未经检查的异常，并将其包装并以 ExceptionInInitializerError 的形式重新抛出。

注意：ExceptionInInitializerError 是一个Error，而不是常规异常。您不应该尝试从中恢复。

大多数情况下，异常无法被捕获：

public class Test {
    static {
        int i = 1;
        if (i == 1) {
            throw new RuntimeException("Bang!");
        }
    }
    
    public static void main(String[] args) {
        try {
            // stuff
        } catch (Throwable ex) {
            // This won't be executed.
            System.out.println("Caught " + ex);
        }
    }
}

$ java Test
Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Bang!
    at Test.<clinit>(Test.java:5)

上面没有地方可以放置 try ... catch 来捕获 ExceptionInInitializerError²。

在某些情况下你可以抓住它。例如，如果您通过调用 Class.forName(...) 触发类初始化，则可以将调用包含在 try 中并捕获 ExceptionInInitializerError 或后续的 NoClassDefFoundError。

但是，如果您尝试从 ExceptionInInitializerError 中恢复，您可能会遇到障碍。问题在于，在抛出错误之前，JVM 将导致问题的类标记为“失败”。您根本无法使用它。此外，依赖于失败类的任何其他类如果尝试初始化也将进入失败状态。唯一的方法是卸载所有失败的类。对于动态加载的代码³来说，可能是可行的，但通常情况下并非如此。

^{1 - 如果静态块无条件抛出未经检查的异常，则这是一个编译错误。
2 - 您也许可以通过注册默认的未捕获异常处理程序来拦截它，但这不允许您恢复，因为您的“主”线程无法启动。
3 - 如果您想恢复失败的类，您需要删除加载它们的类加载器。}

---

这个设计决定背后的原因是什么？

它是为了保护程序员免于编写抛出无法处理的异常的代码……因为程序员没有办法编写处理程序。

正如我们所看到的，静态初始化程序中的异常会将典型的应用程序变成一块砖。语言设计者可以帮助程序员做的最好的事情就是指定检查的情况 1 是编译错误。不幸的是，对于未经检查的异常也这样做是不切实际的。

---

如果您的代码“需要”在静态初始化程序中抛出异常，您应该怎么做？

基本上，有两种选择：

• 如果（完全！）从块内的异常中恢复是可能的，然后这样做。

• 否则，请重构代码，以便初始化不会发生在静态初始化块（或静态变量的初始值设定项中）。将初始化放在可以从常规线程调用的方法或构造函数中。

Answer 5

查看 Java 语言规范 ：据说，如果静态初始化器失败能够突然完成并带有检查异常，则这是一个编译时错误。

Answer 6

由于您编写的代码无法调用静态初始化块，因此抛出已检查的异常是没有用的。如果可能的话，当抛出检查异常时，jvm 会做什么？ 运行时异常向上传播。

Answer 7

例如：Spring 的 DispatcherServlet (org.springframework.web.servlet.DispatcherServlet) 处理捕获一个已检查异常并抛出另一个未检查异常的场景。

static {
    // Load default strategy implementations from properties file.
    // This is currently strictly internal and not meant to be customized
    // by application developers.
    try {
        ClassPathResource resource = new ClassPathResource(DEFAULT_STRATEGIES_PATH, DispatcherServlet.class);
        defaultStrategies = PropertiesLoaderUtils.loadProperties(resource);
    }
    catch (IOException ex) {
        throw new IllegalStateException("Could not load '" + DEFAULT_STRATEGIES_PATH + "': " + ex.getMessage());
    }

Answer 8

我能够编译并抛出一个已检查的异常......

static {
    try {
        throw new IOException();
    } catch (Exception e) {
         // Do Something
    }
}