Les 10 principales questions sur les exceptions en Java

L'article décrit les 10 questions les plus fréquemment posées sur les exceptions en Java.

1. Vérifiable et invérifiable

En bref, les exceptions vérifiées doivent être explicitement interceptées dans le corps de la méthode ou déclarées dans la section throws de la méthode. Les exceptions non vérifiées sont causées par des problèmes qui ne peuvent pas être résolus, tels qu'une division par 0, un pointeur nul, etc. Les exceptions vérifiées sont particulièrement importantes car vous attendez des autres développeurs utilisant votre API qu'ils sachent comment gérer les exceptions. Par exemple, IOException est une exception vérifiée couramment utilisée, tandis que RuntimeException est une exception non vérifiée. Avant de poursuivre votre lecture, consultez Diagramme d'exception hiérarchique en Java .

2. Meilleure façon de gérer les exceptions

Si l’exception peut être gérée correctement, elle doit être interceptée, sinon elle doit être transmise.

3. Pourquoi les variables définies dans try ne peuvent-elles pas être utilisées dans catch ou finalement ?

Dans le morceau de code suivant, la ligne déclarée dans un bloc try ne peut pas être utilisée dans un bloc catch. Ce code ne sera pas compilé.

try {
	File file = new File("path");
	FileInputStream fis = new FileInputStream(file);
	String s = "inside";
} catch (FileNotFoundException e) {
	e.printStackTrace();
	System.out.println(s);
}

La raison en est qu'on ne sait pas exactement où dans le bloc try l'exception a pu être levée. Il est possible que l'exception ait été levée avant la déclaration de l'objet. Et cela est vrai pour cet exemple.

4. Pourquoi Double.parseDouble(null) et Integer.parseInt(null) lèvent-ils des exceptions différentes ?

C'est vrai, ils soulèvent différentes exceptions. Il s'agit d'un problème JDK. Ils ont simplement été conçus par des personnes différentes, et vous ne devriez pas trop vous en soucier.

Integer.parseInt(null);
// вызывает java.lang.NumberFormatException: null

Double.parseDouble(null);
// вызывает java.lang.NullPointerException

5. Exceptions d'exécution de base en Java

En voici quelques-uns :

IllegalArgumentException
ArrayIndexOutOfBoundsException

Ils peuvent être utilisés dans une instruction if lorsque la condition n'est pas remplie, comme ici :

if (obj == null) {
   throw new IllegalArgumentException("obj не может быть равно null");

6. Est-il possible d'intercepter plusieurs exceptions dans un seul bloc catch ?

La réponse est oui. Tant que les classes de ces exceptions peuvent être retracées dans la hiérarchie d'héritage des classes jusqu'à la même superclasse, seule cette superclasse peut être utilisée.

7. Un constructeur peut-il lever des exceptions ?

La réponse est oui. Un constructeur n’est qu’un type particulier de méthode. Voici un exemple de code.

8. Lancer des exceptions dans le bloc final

En principe, vous pouvez tout à fait légalement faire ceci :

public static void main(String[] args) {
	File file1 = new File("path1");
	File file2 = new File("path2");
	try {

		FileInputStream fis = new FileInputStream(file1);
	} catch (FileNotFoundException e) {
		e.printStackTrace();
	} finally {
		try {
			FileInputStream fis = new FileInputStream(file2);
		} catch (FileNotFoundException e) {
			e.printStackTrace();
		}
	}
}

Mais pour maintenir la lisibilité du code, vous devez déclarer le bloc imbriqué try-catchcomme nouvelle méthode et insérer un appel à cette méthode dans le bloc finally.

public static void main(String[] args) {
	File file1 = new File("path1");
	File file2 = new File("path2");
	try {

		FileInputStream fis = new FileInputStream(file1);
	} catch (FileNotFoundException e) {
		e.printStackTrace();
	} finally {
		methodThrowException();
	}
}

9. Est-il possible d'utiliser return dans un bloc final ?

Oui, vous pouvez.

10. Pourquoi les développeurs gèrent-ils les exceptions en silence ?

Par exemple, de tels morceaux de code apparaissent souvent. Si une bonne gestion des exceptions est si importante, pourquoi les développeurs continuent-ils à l’écrire de cette façon ?

try {
     ...
} catch(Exception e) {
     e.printStackTrace();
}

Il est plus facile de l'ignorer. Mais même si cela est souvent fait, cela ne veut pas dire que c’est correct. Liens:

1. Exceptions non vérifiées en Java
2. La racine d'une arborescence d'exceptions hiérarchique en Java
3. Questions sur les exceptions sur stackoverflow

Article original