Pourquoi InstantiationException est-elle une exception vérifiée?

Question

Je crois comprendre que les exceptions vérifiées sont celles dont l'appelant du peut raisonnablement s'attendre à récupérer. Je ne comprends pas pourquoi c'est le cas avec InstantiationException. Si une classe ne peut pas être instanciée, que l'appelant devrait faire?

J'ai alors pensé que c'était peut-être une considération importante que le code avait compilé - donc cela ne pouvait se produire que si une classe est spécifiée dynamiquement.¹ Dans ce cas, la classe peut ressembler davantage à un paramètre, mais nous avons ensuite illégalArgumentException qui est une exception d'exécution.

Quel est le rationnel derrière quelles exceptions standard sont vérifiées et lesquelles ne le sont pas?

¹ Est-ce vrai?

Answer 1

Une des raisons de gérer explicitement cette exception auquel je peux penser (mais ce n'est pas une réponse faisant autorité):

Essayez d'instancier une classe avec réflexion (car cette classe est configurée, pas liée statiquement). S'il n'a pas la signature du constructeur attendu, essayez un autre constructeur. Ou une autre classe. Tout code Framework (comme Spring) peut avoir une telle logique.

Answer 2

Du javadoc pour InstantiationException:

Lancé lorsqu'une application essaie de créer une instance d'une classe en utilisant le newinstance Méthode dans la classe de classe, mais l'objet de classe spécifié ne peut pas être instancié car il s'agit d'une interface ou est une classe abstraite.

Cela ne se produira que lors de l'utilisation de la réflexion Java, par exemple lorsqu'il est programmeur instanciant des objets, par exemple ClassName.class.newInstance() par opposition à new ClassName() pour ainsi dire. Il est naturel de s'attendre à ce que quiconque utilise la réflexion pour écrire du code qui gère de telles aberrations comme instanciation d'une classe abstraite ou d'une interface ou s'il y a une exception lancée pendant l'invocation du constructeur (auquel cas vous pouvez utiliser e.getCause()).

Il ne devrait pas être géré dans votre code - mais plutôt par cette API / bibliothèque particulière qui utilise la réflexion.

Answer 3

Class.newinstance () a une description intéressante sur le lancement d'une instanciationxception Javadoc :

InstantiationException - Si cette classe représente une classe abstraite, une interface, une classe de tableau, un type primitif ou un void; ou si la classe n'a pas de constructeur nulaire; ou Si l'instanciation échoue pour une autre raison.

Pour moi, il semble que cela essaie de couvrir pour tous les cas où l'instanciation de la classe liée statiquement échouerait au moment de la compilation.

La partie la plus importante est la pièce que j'ai mis en évidence. Imaginez un constructeur qui lance une exception vérifiée. Que se passe-t-il si ce constructeur est appelé dynamiquement? Qui vérifiera cette mauvaise exception vérifiée?

Answer 4

Comme vous pouvez le voir sur Javadoc de InstantiationException Javadoc, c'est lancé

Lorsqu'une application essaie de créer une instance d'une classe utilisant la méthode NewInstance dans la classe de classe, mais l'objet de classe spécifié ne peut pas être instancié.

Vous pouvez parfaitement écrire un tel code:

try {
Class myClass = Class.forName("Myclass");
myClass.newInstance();
} catch (ClassNotFoundException e) {
} catch (InstantiationException e) {
} catch (IllegalAccessException e) {
}

non IllegalArgumentException sera lancé.

À propos de checked et unchecked Il s'agit davantage de ce qui a causé l'exception, et non de savoir s'il est facile de récupérer ou non. Veuillez en savoir plus sur checked contre

Answer 5

Bien qu'il existe une vaste zone grise entre les exceptions de contrôle et non contrôlées, et de nombreuses exceptions peuvent être sans doute conçues dans un sens ou dans l'autre, celle-ci ne l'est pas. C'est une erreur, cela aurait dû être incontrôlé.