try et catch en Java
Enveloppe la mauvaise lecture slots[5] dans try et catch pour que le programme ne s’arrête pas sur ArrayIndexOutOfBoundsException. Affiche blocked dans le catch, puis after hors des deux blocs. Compile Guard.java et lance java Guard. L’écran doit montrer blocked, puis after. Un second fichier garde slots[0] dans try pour que le catch soit sauté et que l’écran montre 2, puis after. Laisse throw pour la page suivante.
Attraper le mauvais index
La page des exceptions a montré qu’imprimer slots[5] sur {2, 4} lance ArrayIndexOutOfBoundsException et arrête l’exécution. Cette page garde la même histoire de tableau et ajoute la gestion. Ouvre un nouveau fichier d’enseignement nommé Guard.java. Garde le nom de classe publique Guard pour qu’il corresponde au nom de fichier. Supprime les main restants de Alarm qui s’arrêtent sans catch, les listes Integer de Crate, et tout Scanner ou nextLine. Le programme ne doit pas attendre une saisie.
Dans main, garde le même petit tableau :
int[] slots = {2, 4};
Place l’impression mauvaise dans try :
System.out.println(slots[5]);
Écris ensuite un catch qui nomme ArrayIndexOutOfBoundsException et affiche blocked. Après tout le try et catch, affiche after. Le nom du paramètre catch peut être une lettre courte comme e ; tu n’as pas besoin d’afficher l’objet d’exception sur cette page.
public class Guard {
public static void main(String[] args) {
int[] slots = {2, 4};
try {
System.out.println(slots[5]);
} catch (ArrayIndexOutOfBoundsException e) {
System.out.println("blocked");
}
System.out.println("after");
}
}
Depuis le dossier qui contient Guard.java, lance javac Guard.java. Quand parenthèses, accolades et points-virgules correspondent, javac n’écrit aucune ligne de son côté. Puis lance java Guard — pas java Guard.java. Enlève la fin .java de la commande d’exécution.
L’écran montre blocked, puis after. Le mauvais index lance toujours dans try. Le catch gère cette exception nommée et affiche blocked. La ligne System.out.println("after"); est dehors, donc elle s’exécute encore. Le programme ne s’arrête pas sur cet arrêt comme le fichier mauvais nu de Alarm.
Imagine une seconde impression encore dans le même try après slots[5], par exemple une ligne qui afficherait rice. Cette ligne ne s’exécute pas. Attraper l’exception ne revient pas finir le reste de try. Seul le corps du catch tourne pour cet arrêt, puis le contrôle continue après le catch. Garde l’idée claire : la gestion saute les lignes restantes dans try après le point de lancement.
Si le terminal attend une entrée clavier, un appel nextLine d’un ancien exercice reste dans un fichier. Supprime-le. Si tu ne vois qu’un rapport de pile sans ligne blocked, le catch manque ou le nom d’exception ne correspond pas. Si tu vois seulement 2 sans after, tu lances peut-être encore un ancien Alarm sûr — passe à java Guard avec le fichier d’enseignement du catch.
Quand try se termine, catch reste silencieux
Un second programme utilise la même forme try et catch, mais l’impression dans try demande un emplacement écrit : slots[0]. Chaque ligne dans try se termine. Le corps du catch ne s’exécute pas.
public class Guard {
public static void main(String[] args) {
int[] slots = {2, 4};
try {
System.out.println(slots[0]);
} catch (ArrayIndexOutOfBoundsException e) {
System.out.println("blocked");
}
System.out.println("after");
}
}
Compile avec javac Guard.java, puis lance java Guard. L’écran montre 2, puis after. Le mot blocked n’est pas affiché, car il n’y a pas eu d’ArrayIndexOutOfBoundsException. Le catch est resté silencieux. La ligne after s’exécute encore, car elle est hors des deux blocs — le même endroit que dans la démo catch.
Parcours le contraste une fois. Premier fichier : mauvais index, catch affiche blocked, puis after. Second fichier : index sûr, catch sauté, écran 2 puis after. Les deux gardent Guard et le même nom de type catch. Seul l’index dans try change. Ce seul changement suffit pour voir quand catch s’exécute et quand non.
N’invente pas de throw sur cette page. Tu attrapes une exception qu’une mauvaise lecture de tableau provoque déjà. La page suivante parle de lancer exprès. N’enveloppe pas non plus chaque impression calme du cours dans try aujourd’hui — cette leçon utilise try là où un mauvais index connu a besoin d’un chemin géré.
Le nom du catch doit correspondre
La clause catch nomme un type d’exception. Sur cette page, ce type est ArrayIndexOutOfBoundsException, correspondant au mauvais index. Si tu écrivais catch (NullPointerException e) autour de slots[5], ce catch ne gérerait pas l’arrêt. Le programme finirait encore avec ArrayIndexOutOfBoundsException, et ni blocked ni after ne s’afficheraient pour ce catch non correspondant. Garde le type correspondant dans les fichiers d’enseignement.
D’autres noms d’exception existent en Java. Cette page reste sur une paire claire : un mauvais index de tableau et ArrayIndexOutOfBoundsException. Tu n’as pas besoin d’un catalogue de chaque type attrapable avant de pratiquer cette forme. Fais correspondre le nom vu sur la page des exceptions.
Comparé à l’arrêt nu d’Alarm
Sur la page des exceptions, java Alarm avec slots[5] s’est arrêté et a montré un rapport de pile. Sur cette page, java Guard avec le même mauvais index affiche blocked et continue jusqu’à after. L’histoire du tableau n’a pas changé. La gestion oui. Garde les fichiers Alarm seulement comme histoire s’ils restent proches ; lance java Guard pour les démos catch afin que l’écran corresponde à cette leçon.
L’histoire wrappers imprime encore 9 depuis une liste Integer si tu gardes ce vieux fichier. Ce chemin n’est pas l’histoire du catch. Supprime ou ignore les démos ArrayList<Integer> restantes dans Guard.java pour que le fichier d’enseignement reste sur int[] slots avec try et catch.
Ce que cette page laisse pour throwing
Cette page attrape une exception qu’une ligne rencontre déjà. La page suivante introduit throw pour signaler un problème toi-même. Reste ici avec un catch qui correspond et avec la suite de after. N’ajoute pas encore un throw manuel comme exigence sur ces fichiers Guard.
Avant throwing
Tu peux attraper ArrayIndexOutOfBoundsException depuis slots[5] et voir blocked, puis after. Tu peux garder slots[0] dans try et voir 2, puis after, avec catch sauté. Compile Guard.java et lance java Guard pour chaque démo gardée à tour de rôle. Le nom du catch a correspondu à l’arrêt du mauvais index. La page suivante est throwing, où tu causes un arrêt exprès.
Garde la démo catch pour un chemin géré. Garde le try sûr pour un saut calme du catch. Garde le throw manuel hors de cette page. Ces trois habitudes sont le point de contrôle avant d’avancer. Quand blocked puis after apparaissent après l’exécution du mauvais index de java Guard, try et catch ont fait leur travail pour cette leçon et tu es prêt pour le sujet suivant sur le lancement.
🧠 Testez Vos Connaissances
Testez Vos Connaissances
Mettez-vous au défi avec ce quiz interactif et voyez à quel point vous comprenez le sujet
📝 Instructions
- Lisez chaque question attentivement
- Sélectionnez la meilleure réponse pour chaque question
- Vous pouvez refaire le quiz autant de fois que vous le souhaitez
- Votre progression sera affichée en haut