Exceptions Java vérifiées et non vérifiées

Les exceptions Java sont divisées en deux types, les exceptions vérifiées et les exceptions non vérifiées. Un autre nom est les exceptions et les erreurs.

En termes simples, les vérifications peuvent être récupérées pendant l'exécution, tandis que les exceptions non vérifiées sont des erreurs qui ne peuvent pas être gérées.

exception cochée :

signifie invalide et ne peut pas être prédit dans le programme. Par exemple, entrée utilisateur non valide, fichier n'existe pas, erreur de lien réseau ou base de données. Ce sont toutes des raisons externes et ne peuvent pas être contrôlées au sein du programme.

doit être géré explicitement dans le code. Par exemple, effectuez un traitement de bloc try-catch ou ajoutez une description de lancement à la méthode pour lever l'exception vers la couche supérieure de la pile d'appels.

Hérite de java.lang.Exception (sauf java.lang.RuntimeException).

exception non cochée :

indique une erreur, une erreur logique dans le programme. Est une sous-classe de RuntimeException, telle que IllegalArgumentException, NullPointerException et IllegalStateException.

Il n'est pas nécessaire d'intercepter explicitement les exceptions non vérifiées dans le code pour la gestion.

Hérite de java.lang.RuntimeException (et java.lang.RuntimeException hérite de java.lang.Exception).

L'exception vérifiée en Java doit être explicitement interceptée ou renvoyée par try-catch dans le code. Si vous n'avez pas besoin de gérer cette exception, vous pouvez simplement lancer à nouveau l'exception. Cette exception existe. L'inconvénient est que de nombreuses personnes sont habituées à écrire un bloc catch vide directement dans le code. Cela rend non seulement le code redondant et "laid", mais pose également des problèmes de débogage et augmente la difficulté de maintenance du code. Ainsi, certaines personnes disent que vérifié rend le code verbeux et que les blocs catch vides n'ont aucun sens, donc les exceptions vérifiées devraient être supprimées du standard Java. Par exemple, il n'y a pas de concept d'exceptions vérifiées en C#, et C# ne force pas la capture explicite de. exceptions.

La raison pour laquelle les exceptions Java sont divisées en ces deux types devrait être due aux considérations suivantes :

Les exceptions vérifiées peuvent aider les développeurs à comprendre quelles lignes peuvent provoquer des exceptions, car l'API de Java a été expliquée. quelles méthodes peuvent être appelées pour lever une exception. S'il n'est pas traité, la compilation échouera. Dans une certaine mesure, cette approche peut éviter certaines erreurs dans le programme.

Deux exemples simples

1. exception vérifiée

import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
public class Main {
public static void main(String[] args) {
File f = new File("C:\test.txt");
FileReader r = new FileReader(f); //A
BufferedReader br = new BufferedReader(r);
br.readLine(); //B
br.close(); //C
}
}

Ce code ne peut pas être compilé car A , les lignes B et C lancera IOException. Vous devez mettre ce code dans un bloc try-catch, ou ajouter throws IOException à la méthode principale pour compiler.

2. Exception non vérifiée

public class Main {
public static void main(String[] args) {
int a = 0;
int b = 100;
int c = b/a;
}
}

Peut être compilée, mais une erreur sera signalée lors de son exécution

Exception in thread “main” java.lang.ArithmeticException: / by zero
at Main.main(Main.java:13)

ArithmeticException est une exception non vérifiée.

Exception personnalisée

1. exception vérifiée

Classe d'exception personnalisée InvalidUrlException

public class InvalidUrlException extends Exception {
public InvalidUrlException(String s){
super(s);
}
}

public class Main {
public static void getRemoteData(String url) throws InvalidUrlException{
if(isValidUrl(url)){
//获取远程数据
}
else
throw new InvalidUrlException("Invalid URL: " + url);
}
public static boolean isValidUrl(String url){
.... //验证URL是否有效
}
public static void main(String[] args) {
getRemoteData(args[0]);
}
}

Si getRemoteData est appelé dans la méthode principale, il y a Il existe deux méthodes, l'une est try-catch et l'autre consiste à ajouter directement une exception InvalidUrlException à main.

2. exception non vérifiée

Si vous remplacez InvalidUrlException par extends RuntimeException

public class InvalidUrlException extends Exception {
public InvalidUrlException(String s){
super(s);
}
}

, alors main n'a pas besoin d'ajouter de lancers ou de try-catch.

Sélectionner une exception cochée ou non cochée ?

Certains livres Java recommandent d'utiliser des gestionnaires d'exceptions vérifiés pour toutes les exceptions récupérables et des exceptions non vérifiées pour les erreurs irrécupérables. Mais en fait, la plupart des exceptions Java héritées de RuntimeException peuvent également être récupérées dans le programme. Par exemple, NullPointerException, IllegalArgumentExceptions, les exceptions de division par 0, etc. peuvent être capturées et traitées pour permettre au programme de continuer à s'exécuter. Seules certaines circonstances particulières perturberont l'exécution du programme, comme la lecture du fichier de configuration au démarrage. Si le fichier de configuration n'existe pas ou s'il y a une erreur grave, le programme doit se terminer.

Voici quelques arguments pour et contre les exceptions vérifiées :

Le compilateur force à intercepter ou à lancer des exceptions non vérifiées afin que les développeurs se souviennent toujours de gérer les exceptions.

Les méthodes qui lancent des exceptions vérifiées doivent déclarer les lancers. Les lancers deviennent une partie de la méthode ou de l'interface, ce qui entraîne des inconvénients pour les versions ultérieures lors de l'ajout ou de la modification d'exceptions de méthode.

Les exceptions non vérifiées n'ont pas besoin d'être traitées explicitement mais rendent la gestion des exceptions difficile.

Lors de l'appel d'une méthode d'exception vérifiée, vous devez gérer l'exception de cette méthode, ce qui rend le code de l'appelant supérieur déroutant.

C'est à vous de décider si vous choisissez coché ou décoché. Il est difficile de dire lequel est définitivement correct, et vice versa. Parmi les langages les plus populaires à l'heure actuelle, Java semble être le seul à prendre en charge les exceptions vérifiées, et les autres langages n'ont que des exceptions non vérifiées.

Ce qui précède est le contenu des exceptions cochées et non cochées de Java. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !