CODEWITHSUNDEEP
javaexceptionclassnotfoundexception
Rafael
Rafael

Reputation: 2676

Reason for ClassNotFoundException to be a checked exception

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.

Upvotes: 12

Views: 16918

Answers (3)

Stephen C
Stephen C

Reputation: 719739

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

Upvotes: 5

Mike Samuel
Mike Samuel

Reputation: 120586

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.

Upvotes: 7

mszalbach
mszalbach

Reputation: 11490

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

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

Now is the question can the program recover from a 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.

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.

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.

Upvotes: 1

Related Questions