Considérez le code suivant
private int meth()
{
try
{
return 1;
}
catch(MyException me)
{
return 2;
}
finally
{
return 3;
}
}
3 Réponses :
En ce qui concerne le compilateur, vous pouvez à tout moment obtenir une exception de dépassement de pile, une exception de mémoire, une exception arithmétique ou un nombre quelconque d'autres exceptions générées par la JVM. D'autre part, il peut analyser statiquement que essaie bloquer et voir que myException n'est jamais lancé, alors il jette ses mains vers le haut. Il sait que cela ne sera jamais lancé par la JVM.
Ce serait ma supposition - que, parce que cela traite des exceptions JVM comme une exception que cela peut être lancé - mais il sait qu'une exception définie par l'utilisateur ne peut être lancée à moins d'appeler un appel "lancer" n'importe où dans l'essai.
La raison de ce comportement est que les seules exceptions non cochées dans la langue Java sont des points de vue de la Java et de ses sous-classes. Toutes les autres exceptions et erreurs, y compris la vôtre, car il ne présente que des interclasses (et non de la runtimeexception) sont des exceptions vérifiées.
La raison pour laquelle le premier exemple de code n'est pas marqué par le compilateur, bien qu'il utilise la classe d'exception comme instruction de capture, est dû à la hiérarchie de la classe. Étant donné que toutes les exceptions découlent de l'exception, votre code n'atteint pas spécifiquement une exception, mais attraper toutes les exceptions et les jeter à une instance d'exception. Ainsi, il n'existe aucun moyen que le compilateur indique si l'exception qui sera prise au moment de l'exécution est une exception vérifiée ou décochée. Dans le deuxième bloc de code, il n'ya aucun moyen de ne pas être une exception vérifiée. Par conséquent, le compilateur peut déterminer que votre bloc de capture est inaccessible.
+1 - J'allais écrire juste ça ... Regardez la hiérarchie héritabilité d'exception ... c'est tout là :-)
en Java, décoché (RunTimeExceptions) et une exception vérifiée tous dérivent de l'exception.
Dans votre exemple, dans le premier cas, le bloc de capture peut attraper une ruée à la ruintimeeXception (vous bénéficiez du doute ici) ou de toute exception vérifiée et que vous ne vous plaignez pas de l'exception non capturée.
Cependant, dans le second cas, car vous avez explicitement mentionné un type d'exception qui est vérifié et qui n'est pas lancé dans une partie de votre code et donne donc une erreur.
Ce bloc de capture n'est pas applicable pour RTException.in ce cas particulier, vous n'avez pas l'avantage de douter que le compilateur avait dans votre premier scénario.