Reason for ClassNotFoundException to be a checked exception

Question

What is the reason behind ClassNotFoundException being a checked exception?

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.

Answer 1

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

Unchecked Exceptions — The Controversy says:

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

classLoader.loadClass(className);

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

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

What distinguishes the reflective use case (checked) from a failure to link statically compiled 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.

Rephrasing

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

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.

Answer 2

A ClassNotFoundException is 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 could be a recoverable error ... in some circumstances ... so you could argue that the decision to make it checked is appropriate.

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.

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 NoClassDefFoundError if 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 ...)