(I) Hiérarchie d'exception de Java
Pour comprendre la différence entre l'exception vérifiée et l'exception non contrôlée en Java, examinons d'abord la hiérarchie d'exception de Java.
Il s'agit d'un diagramme de hiérarchie d'exception Java simplifié. Il convient de noter que toutes les classes sont héritées de Thrownable, et la couche suivante est divisée en deux structures, erreur et exception. Le niveau de classe d'erreur décrit les erreurs internes et les erreurs d'épuisement des ressources dans le système d'exécution Java. En plus de simplement signaler cette erreur à l'utilisateur et d'essayer d'éviter que le programme soit terminé en toute sécurité, il existe généralement d'autres solutions.
(Ii) la différence entre l'exception non contrôlée et l'exception vérifiée
Après avoir compris ce qui précède, jetons un coup d'œil à ce qui est vérifié et à une exception non contrôlée. En fait, la spécification du langage Java définit ces deux très simples. Les exceptions dérivées de l'erreur ou du runtimeException sont appelées exceptions non contrôlées, et toutes les autres exceptions deviennent des exceptions vérifiées . Bien que cette définition soit très simple, RuntimeException est un concept très déroutant. Il semble que toutes nos exceptions soient en train d'exécuter le programme. Mon explication de Ru ntimeexception dans Java efficace n'est pas si satisfaisante.
Utilisez des exceptions vérifiées pour les conditions récupérables et les exceptions d'exécution pour les erreurs de programmation (article 58 en 2e édition)
Cependant, à partir de cette phrase, nous pouvons simplement l'étendre, c'est-à-dire que si une conception RuntimeException se produit, cela doit être un problème pour le programmeur lui-même. Par exemple, les indices de tableau sont hors limites et accéder aux exceptions du pointeur nul, etc. Tant que vous faites un peu d'attention, ces exceptions sont des exceptions qui peuvent être évitées au stade de codage. Si vous pensez toujours que ces deux concepts sont difficiles à distinguer, la méthode "la plus violente" consiste à mémoriser la conception courante, ce qui peut gagner beaucoup de temps pour juger.
(Iii) Pourquoi devrions-nous faire la distinction entre les exceptions non contrôlées et les exceptions vérifiées?
La raison est en fait très simple. Le compilateur vérifiera si vous fournissez un mécanisme de gestion des exceptions pour toutes les exceptions vérifiées. Par exemple, lorsque nous utilisons class.forname () pour trouver l'objet de classe d'une chaîne donnée, si la gestion des exceptions n'est pas fournie pour cette méthode, la compilation ne sera pas transmise.
(Iv) Quelles exceptions devons-nous déclarer?
Comme nous l'avons dit plus tôt, RuntimeException est une erreur qui peut être évitée pendant le processus de programmation. Alors n'avons-nous pas besoin de lancer ces exceptions? En principe, cela est vrai, mais la spécification Java ne limite pas cela. Il semble simplement que vous jettez un tableau hors des limites et qu'il n'y a aucune signification pratique, et au contraire, cela entraînera certaines pertes de performance. Alors, comment devrions-nous concevoir des exceptions de lancer? Nous devons nous rappeler que les deux situations suivantes sont nécessaires pour déclarer des exceptions de lancers:
Appelez une méthode d'exception vérifiée, comme IOException. Quant à la raison, nous avons discuté plus tôt, si toutes les exceptions vérifiées sont lancées, elle ne peut pas être compilée. Une erreur a été trouvée pendant le programme en cours d'exécution et une exception a été lancée à l'aide de l'instruction Throw. Pour les exceptions non contrôlées, il n'y a que deux situations principales: soit évitables (exception d'exécution) ou incontrôlables. Ceux-ci nécessitent également une déclaration d'exceptions.
Voici des exemples pour illustrer les choses maladroites mentionnées dans la note 2 ci-dessus:
Tout d'abord, définissez une classe d'exception de base Generricexception, héritée de l'exception.
package check_unchecked_exceptions; classe publique Generricexception étend une exception {/ ** * * / private static final long SerialVersionUID = 2778045265121433720l; public generICyException () {} public generICyException (String msg) {super (msg); }} Ce qui suit définit une classe de test VerifyException.
package Check_Unchecked_Exceptions; public class VerifyException {public void First () lève GenerIdException {throw new Generricexception ("Exception vérifiée"); } public void second (String msg) {if (msg == null) {throw new nullpointerException ("exception non cochée"); }} public void tiers () lève GenerRicexception {first (); } public static void main (String [] args) {VerifyException ve = new VerifyException (); essayez {ve.first (); } catch (genedicexception e) {e.printStackTrace (); } ve.second (null); }}Après avoir exécuté, obtenez les informations suivantes sur la console d'Eclipse:
check_unchecked_exceptions.generIcexception: exception vérifiée
sur check_unchecked_exception.verifyException.first (VerifyException.java:6)
sur check_unchecked_exception.verifyException.main (VerifyException.java:23)
Exception dans Thread "Main" java.lang.nullpointerException: exception non contrôlée
sur check_unchecked_exception.verifyException.second (VerifyException.java:11)
sur check_unchecked_exception.verifyException.main (VerifyException.java:29)
Dans l'exemple ci-dessus, combiné avec les concepts de vérification et de non-vérification, on peut voir que l'exception de la classe parent est de type vérifié, mais sa sous-classe RuntimeException (sous-classe NullPointerException) n'est pas contrôlée.
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.