Why is InstantiationException a checked exception?

Question

My understanding is that checked exceptions are those that the caller of the can reasonably be expected to recover from. I don't understand why this is the case with InstantiationException. If a class cannot be instantiated then what is the caller expected to do?

I then thought that maybe it was an important consideration that the code had compiled - therefore this could only happen if a class is dynamically specified.¹ In this case the class may be more like a parameter, but then we have IllegalArgumentException that is a runtime exception.

What is the rational behind which standard exceptions are checked, and which are not?

¹ Is this true?

Answer 1

One reason for explicitly handling this exception that I can think of (but that's not an authoritative answer):

Try instanciating a class with reflection (because that class is configured, not statically linked). If it doesn't have the expected constructor signature, try another constructor. Or another class. Any framework code (such as Spring) might have such logic.

Answer 2

From the JavaDoc for InstantiationException:

Thrown when an application tries to create an instance of a class using the newInstance method in class Class, but the specified class object cannot be instantiated because it is an interface or is an abstract class.

This will only happen when using Java reflection, e.g. when programmatically instantiating objects, e.g. ClassName.class.newInstance() as opposed to new ClassName() so to speak. It is only natural to expect whoever uses reflection to write code that handles any such aberrations like instantiating an abstract class or an interface or if there is an exception thrown in during the constructor invocation (in which case you can use e.getCause()).

It is not expected to be handled in your code -- but rather by that particular API/library that uses reflection.