java ClassNotFoundException 成为受检异常的原因

Reason for ClassNotFoundException to be a checked exception

提问by Rafael

What is the reason behind ClassNotFoundExceptionbeing a checked exception?

ClassNotFoundException成为受检异常背后的原因是什么？

I've been guessing and googling trying to understand why consider class not found as checked exception, because all my mind tells me that it should be unchecked.

我一直在猜测和谷歌搜索，试图理解为什么将未找到的类视为已检查的异常，因为我所有的想法都告诉我它应该是未经检查的。

采纳答案by Mike Samuel

Exceptions are usually checked when the receiver can/should take some meaningful action to correct the problem at runtime.

当接收者可以/应该采取一些有意义的行动来纠正运行时的问题时，通常会检查异常。

Unchecked Exceptions — The Controversysays:

未经检查的异常——争议说：

Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

这是底线准则：如果可以合理地期望客户端从异常中恢复，请将其设为已检查异常。如果客户端无法从异常中恢复，请将其设为未经检查的异常。

The most common source of ClassNotFoundExceptions is code like

最常见的ClassNotFoundExceptions来源是像这样的代码

classLoader.loadClass(className);

that reflectivelyloads a class based on a name found in a configuration file, serialized input, or remote procedure call.

该反射性负载基于一名称的类在配置文件中，序列化输入，或远程过程调用找到。

This is in contrast to ClassNotFoundErrorwhich most often result from a program that was staticallycompiled with other classes which cannot be found by the JVM's linker at runtime.

这与ClassNotFoundError最常见的结果形成对比的是，程序与其他类一起静态编译，JVM 的链接器在运行时无法找到这些类。

What distinguishes the reflectiveuse case (checked) from a failure to link staticallycompiled code (runtime error)?

反射用例（已检查）与无法链接静态编译代码（运行时错误）的区别是什么？

---

---

Context

语境

Reflective: The caller knows where the string came from and why the load was attempted.

反射性：调用者知道字符串的来源以及尝试加载的原因。

Static: Caller is just trying to use a class that was available at compile time. No context is available.

静态：调用者只是尝试使用在编译时可用的类。没有可用的上下文。

Recovery

恢复

Reflective: Caller can fail-over to a different implementation or try a default strategy.

反思：调用者可以故障转移到不同的实现或尝试默认策略。

Static: The Java language does not explicitly support substituting different link points.

静态：Java 语言不明确支持替换不同的链接点。

Rephrasing

改写

Reflective: Caller should often convert the error to a different kind, like
an IOExceptionon failure to deserialize.

反思：来电要经常错误转换为不同的种类，像
一个IOException失败反序列化。

Static: If part of your program is missing, then you can't rely on the necessary part of your program being there to explain why one part is missing to other parts.

静态：如果您的程序的一部分丢失，那么您不能依赖程序的必要部分在那里来解释为什么一个部分缺少其他部分。

回答by Stephen C

A ClassNotFoundExceptionis thrown when your code calls Class.forName()on a class name that cannot be resolved to a class on your application's classpath (loosely speaking). It could be a misspelled classname supplied by the application's user, and hence there is potentially a reason to report it to the user and maybe even retry with a corrected classname. In other words this couldbe a recoverable error ... in some circumstances ... so you could argue that the decision to make it checked is appropriate.

ClassNotFoundException当您的代码调用Class.forName()无法解析为应用程序类路径上的类的类名时，会抛出A （粗略地说）。它可能是应用程序用户提供的拼写错误的类名，因此可能有理由将其报告给用户，甚至可能使用更正的类名重试。换句话说，这可能是一个可恢复的错误......在某些情况下......所以你可以争辩说检查它的决定是合适的。

Either way:

无论哪种方式：

• the "correctness" of any choice between checked versus unchecked is a matter opinion, not objective fact,
• in the past, the Java designers have made the wrong choice in some cases, and
• once the choice is made, there's no going back ... without breaking backwards compatibility.

• 在检查与未检查之间进行任何选择的“正确性”是一种意见，而不是客观事实，
• 过去，Java 设计者在某些情况下做出了错误的选择，并且
• 一旦做出选择，就没有回头路……不会破坏向后兼容性。

By contrast, if you get a problem during the class loading / initialization process, you are likely to get a NoClassDefFoundError. This is definitely not recoverable. When that happens you've got one or more classes in a state where they exist in the JVM but cannot be initialized or instantiated. (You will also see NoClassDefFoundErrorif the JVM fails to find your nominated entrypoint class. But if that happens, your application won't even get a chance to try to recover ...)

相比之下，如果您在类加载/初始化过程中遇到问题，您很可能会得到一个NoClassDefFoundError. 这绝对是无法恢复的。当这种情况发生时，您将有一个或多个类处于它们存在于 JVM 中但无法初始化或实例化的状态。（您还将看到NoClassDefFoundErrorJVM 是否无法找到您指定的入口点类。但如果发生这种情况，您的应用程序甚至没有机会尝试恢复......）

回答by mszalbach

Unchecked Exceptions are used for errors were your program can not recover from. Checked Exceptions are for invalid conditions were you can recover from.

Unchecked Exceptions 用于您的程序无法从中恢复的错误。Checked Exceptions 适用于您可以从中恢复的无效条件。

And as far as I know the concept of checked exceptions only exist in Java.

据我所知，检查异常的概念只存在于 Java 中。

Now is the question can the program recover from a ClassNotFoundException?

现在的问题是程序能否从 ClassNotFoundException 中恢复？

This is thrown most of the time by the method Class.forName. This depends on your program and so the concept of checked and unchecked is a little bit random, because how should the API developer know if my program can recover from it or not. When I need the class at runtime and can not process this would be a unchecked for me however when I ask the user for something and load a class based on this maybe the input is just wrong and I can ask him for something else. But most of the time I would say you can not recover from it and it would be better to be a unchecked.

这在大多数情况下由方法 Class.forName 抛出。这取决于您的程序，因此检查和未检查的概念有点随机，因为 API 开发人员应该如何知道我的程序是否可以从中恢复。当我在运行时需要该类并且无法处理时，这对我来说是未经检查的，但是当我向用户询问某些内容并基于此加载类时，可能输入是错误的，我可以向他询问其他内容。但大多数时候我会说你无法从中恢复，最好是不受约束的。

However in my opinion checked exceptions are used by the api and third-parties to remind the programmer that this problem can occur and the need to think about it. And since loading something based on a pure String could fail and is not compatible with the whole Java static typed language concept the exception is marked as checked so you are reminded that you destroy your static safety. However this is just my opinion.

但是在我看来，api和第三方使用checked异常来提醒程序员可能会出现这个问题，需要考虑一下。由于加载基于纯字符串的内容可能会失败并且与整个 Java 静态类型语言概念不兼容，因此异常被标记为已检查，因此提醒您破坏了静态安全性。然而，这只是我的意见。

In the end the decision is made by the developer of the exception and he can be wrong or right or maybe thought about some other reasons as I.

最后，决定是由异常的开发人员做出的，他可能是错的，也可能是对的，或者可能像我一样考虑其他一些原因。