Exceptions et fichiers en Java

Une exception est un objet qui décrit un problème interrompant un programme en cours d’exécution. La lever arrête l’instruction en cours. Java ignore le travail normal restant jusqu’à trouver un gestionnaire correspondant ; à défaut, l’exception remonte par les méthodes appelantes.

Reconnaître le type de problème

Un point-virgule manquant est une erreur de compilation : le programme ne peut pas compiler. Une exception se produit lorsque du code compilé s’exécute avec des données qui déclenchent un problème.

Les indices de tableau commencent à 0 : une longueur de 3 signifie donc que les indices valides sont 0, 1 et 2. La division en virgule flottante suit d’autres règles : 10.0 / 0 produit Infinity ; elle ne lève pas l’exception de division entière.

Lire une trace depuis le haut

Voici une classe complète, sans ligne vide avant la première ligne :

public class Average {
    static int average(int[] values) {
        int sum = 0;
        for (int value : values) sum += value;
        return sum / values.length;
    }
    public static void main(String[] args) {
        int[] values = new int[0];
        System.out.println(average(values));
    }
}

Le tableau est vide, sa longueur est donc de 0. La division à la ligne 5 échoue. Voici la trace :

Exception in thread "main" java.lang.ArithmeticException: / by zero
    at Average.average(Average.java:5)
    at Average.main(Average.java:9)

1. Lis la première ligne pour connaître la classe et le message de l’exception.
2. Lis le premier cadre at pour trouver où le problème a été détecté.
3. Descends pour trouver les appelants : main a appelé average à la ligne 9.
4. Si les premiers cadres appartiennent à la bibliothèque Java, trouve le premier cadre qui nomme ta propre classe. Pour un appel à Integer.parseInt qui échoue, des cadres de bibliothèque peuvent précéder l’appel dans ton code.

La trace suit la pile d’appels, c’est-à-dire la chaîne des appels de méthodes actifs. Elle t’indique où chercher, mais la valeur incorrecte peut avoir été créée plus tôt. Ici, la division détecte le problème ; l’appelant a fourni le tableau vide. Décide si une entrée vide doit être rejetée ou traitée avant le calcul d’une moyenne.

Examiner l’objet exception

e.getMessage() renvoie le message et peut renvoyer null. e.toString() comprend le nom de la classe et, s’il existe, le message. e.printStackTrace() affiche la trace sur le flux d’erreur standard. Une section Caused by: montre une exception antérieure conservée dans une exception qui l’encapsule.

Les messages NullPointerException produits par la JVM indiquent normalement l’expression nulle. Une exception créée explicitement peut en revanche avoir un message personnalisé ou aucun message. Remonte la référence jusqu’à l’endroit où elle aurait dû recevoir un objet.

Une exception non gérée qui sort de main met fin au thread principal ; cela met fin à un programme à un seul thread. Corrige dans le code les bogues comme les indices incorrects. Prévois une reprise pour les problèmes externes attendus, comme un fichier manquant ou une saisie utilisateur invalide.

Les classes d’exceptions utilisent les règles d’héritage que tu connais déjà. Un objet levé d’une sous-classe appartient aussi à sa superclasse, ce qui explique à la fois les catégories d’exceptions de Java et la façon dont un gestionnaire leur correspond.

Suivre la hiérarchie

Seuls les objets de Throwable ou de ses sous-classes peuvent être levés. Deux branches principales se trouvent en dessous :

Throwable
  Error
    OutOfMemoryError
    StackOverflowError
  Exception
    RuntimeException
      IllegalArgumentException
        NumberFormatException
      NullPointerException
      IndexOutOfBoundsException
        ArrayIndexOutOfBoundsException
    IOException
      FileNotFoundException
      NoSuchFileException

Error décrit des défaillances graves de l’environnement d’exécution. Une application ordinaire ne devrait pas tenter de reprendre l’exécution après un épuisement du tas ou de la pile dû à une récursion sans fin. Exception décrit des problèmes qu’une application peut gérer, y compris sa branche RuntimeException.

Les deux types sont levés à l’exécution. Le mot « contrôlée » indique que le compilateur vérifie la gestion de l’exception ; il ne désigne pas un moment antérieur où l’échec se produirait. Non contrôlée ne signifie pas non plus sans danger : une référence nulle non gérée peut arrêter un programme.

Appliquer la capture ou la déclaration

La lecture d’un fichier peut échouer même dans un code correct. Une méthode auxiliaire peut laisser la décision à son appelant :

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.List;

class Names {
    static List<String> load(Path file) throws IOException {
        return Files.readAllLines(file);
    }
}

Files.readAllLines peut lever l’exception contrôlée IOException. La déclaration transmet cette possibilité à l’appelant, qui doit lui aussi l’intercepter ou la déclarer. Supprimer throws IOException sans ajouter de gestionnaire empêche la compilation de la méthode auxiliaire. Une méthode utilisant Integer.parseInt n’a pas d’obligation comparable imposée par le compilateur, car NumberFormatException est non contrôlée.

Les erreurs contrôlées décrivent souvent des situations qu’un appelant peut prévoir, comme la disparition d’un fichier. Les erreurs d’exécution indiquent souvent des bogues ou des arguments invalides. Ces raisons sont utiles pour la conception, mais c’est la chaîne de superclasses qui détermine la catégorie. Une classe personnalisée qui étend RuntimeException reste non contrôlée même lorsqu’un appelant pourrait reprendre l’exécution.

Faire correspondre les gestionnaires grâce à l’héritage

catch (IOException e) peut gérer une FileNotFoundException ou une NoSuchFileException. catch (Exception e) intercepte aussi les exceptions d’exécution ; il peut transformer un bogue du code en message trompeur sur une saisie. catch (Throwable e) atteint aussi la branche Error et convient rarement à une reprise ordinaire.

Pour classer une classe inconnue, remonte sa chaîne d’héritage dans la documentation de l’API. InputMismatchException étend NoSuchElementException, qui étend RuntimeException : elle est donc non contrôlée. InterruptedException étend Exception hors de la branche des exceptions d’exécution : elle est donc contrôlée. Déclarer un type non contrôlé dans une clause throws est autorisé, mais ne change pas sa catégorie.

Un bloc try délimite un travail qui peut échouer. Un bloc catch correspondant donne au programme une action utile à effectuer ensuite, comme demander une autre valeur. La gestion de l’exception ne relance pas à elle seule l’instruction qui a échoué.

Suivre les branches

System.out.println("A");
try {
    System.out.println("B");
    int value = Integer.parseInt("4x");
    System.out.println("C");
} catch (NumberFormatException e) {
    System.out.println("D: " + e.getMessage());
}
System.out.println("E");

La sortie est A, B, D: For input string: "4x" et E, chacun sur sa propre ligne. La conversion échoue ; Java ignore donc C et entre dans le gestionnaire correspondant. Lorsque ce gestionnaire se termine normalement, l’exécution reprend après l’ensemble de l’instruction. Si la conversion réussit, le gestionnaire est ignoré. Si le bloc lève une ArithmeticException, ce gestionnaire ne correspond pas ; l’exception se propage.

Réessayer avec une nouvelle saisie

Lis une ligne entière avant de la convertir. La boucle ci-dessous accepte un entier et gère la fin de la saisie au clavier en signalant qu’aucune valeur n’a été fournie :

import java.util.Scanner;

class WholeNumbers {
    static int readWholeNumber(Scanner in) {
        while (in.hasNextLine()) {
            String line = in.nextLine();
            try {
                return Integer.parseInt(line.trim());
            } catch (NumberFormatException e) {
                System.out.println("Please enter a whole number.");
            }
        }
        throw new IllegalStateException("No number supplied");
    }
}

Pour les saisies "twenty" et "20", le gestionnaire affiche le message une fois, la boucle lit une nouvelle ligne et la méthode renvoie 20. trim() supprime les caractères blancs en début et en fin de chaîne : sans cela, Integer.parseInt(" 20") échoue. La conversion accepte un signe facultatif et des chiffres représentant un entier dans l’intervalle autorisé.

Un scanner qui lit des jetons nécessite une autre correction. Lorsque nextInt() rencontre "ten", son InputMismatchException laisse ce jeton non lu. Intercepter l’exception et rappeler nextInt() répète l’échec indéfiniment. Consomme le jeton incorrect avec next() ou écarte la ligne avec nextLine() avant de réessayer. hasNextInt() peut vérifier un jeton avant la conversion.

Garder un état utilisable après la reprise

Une variable déclarée dans try n’existe que dans ce bloc. Si le code ultérieur a besoin du résultat, déclare-la à l’extérieur et assure-toi que chaque chemin qui continue lui affecte une valeur valide :

int quantity;
try {
    quantity = Integer.parseInt("bad");
} catch (NumberFormatException e) {
    quantity = 0;
}
System.out.println(quantity);

Zéro ne convient ici que si le programme le définit comme une valeur de remplacement valide. Laisser quantity sans affectation dans le gestionnaire provoque une erreur de compilation liée à l’affectation certaine.

Intercepte le type précis que tu peux gérer. Un gestionnaire vide fait silencieusement perdre le problème ; un catch (Exception e) général peut présenter un bogue de référence nulle comme un nombre incorrect. La reprise doit redemander une saisie, ignorer un élément, choisir une valeur par défaut valide, signaler l’échec ou transmettre une exception explicite. Pour des bornes simples et prévisibles, vérifie d’abord : index >= 0 && index < list.size() évite les indices de liste négatifs comme les indices trop grands.

Un fichier peut être manquant, illisible ou rempli d’enregistrements mal formés. Ces échecs nécessitent des réponses différentes. Plusieurs gestionnaires permettent à un try de les distinguer, tandis que la position du bloc détermine quelle partie du travail s’arrête en cas d’échec.

Placer d’abord les gestionnaires spécifiques

Java teste les gestionnaires de haut en bas et exécute le premier qui correspond. Il ne continue pas à exécuter les gestionnaires suivants pour la même exception.

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.NoSuchFileException;
import java.nio.file.Path;

class FirstCount {
    static void show(Path file) {
        try {
            int count = Integer.parseInt(Files.readString(file).trim());
            System.out.println(count);
        } catch (NoSuchFileException e) {
            System.out.println("File not found: " + file.toAbsolutePath());
        } catch (IOException e) {
            System.out.println("Could not read: " + file.toAbsolutePath());
        } catch (NumberFormatException e) {
            System.out.println("The file must contain one whole number.");
        }
    }
}

NoSuchFileException étend IOException, elle doit donc venir en premier. Inverser leur ordre rend le gestionnaire spécifique inaccessible et empêche la compilation. L’exception de conversion n’a pas de lien avec IOException ; ces deux gestionnaires peuvent donc apparaître dans n’importe quel ordre.

Un gestionnaire d’exception contrôlée doit aussi correspondre à une exception que le travail protégé peut lever. Intercepter IOException autour de la seule instruction int count = 5; est rejeté, car ce bloc ne peut pas la lever. Cette restriction ne s’applique pas de la même façon aux types non contrôlés ni aux types généraux Exception et Throwable.

Partager un gestionnaire lorsque la réponse est la même

Une capture multiple réunit des types d’exceptions sans lien entre eux avec | :

try {
    String[] parts = "Ana".split(",");
    int age = Integer.parseInt(parts[1]);
    System.out.println(age);
} catch (NumberFormatException | ArrayIndexOutOfBoundsException e) {
    System.out.println("Invalid record: " + e.getMessage());
}

Ici, l’absence du deuxième champ déclenche l’exception d’indice. Un champ présent mais non numérique déclencherait l’exception de conversion, et les deux reçoivent la même réponse. Le paramètre de la capture multiple est implicitement final. Les types proposés ne peuvent pas être une sous-classe et sa superclasse : FileNotFoundException | IOException est invalide car IOException couvre déjà les deux.

Décider ce qu’un échec doit faire ignorer

Considère les textes "3", "x" et "5". Avec un try autour de toute la boucle, le traitement s’arrête à "x" et la somme obtenue jusque-là est de 3. Place le try dans la boucle pour reprendre séparément après chaque élément :

int sum = 0;
for (String text : new String[] {"3", "x", "5"}) {
    try {
        sum += Integer.parseInt(text);
    } catch (NumberFormatException e) {
        System.out.println("Skipped: " + text);
    }
}
System.out.println(sum);

Ce code affiche Skipped: x puis 8. La boucle continue car son corps a géré l’échec de cet enregistrement. Avec des gestionnaires imbriqués, la recherche part du bloc protégé le plus interne et progresse vers l’extérieur ; si un gestionnaire interne ne correspond pas, un gestionnaire extérieur peut encore intercepter l’exception. Choisis la plus petite unité de travail qui doit échouer dans son ensemble : un enregistrement pour des données incorrectes, l’opération sur le fichier pour une erreur de lecture.

Certaines opérations doivent avoir lieu, qu’une action réussisse ou échoue. Un bloc finally s’exécute lorsque le contrôle quitte son instruction try, y compris lorsqu’une exception se propage ou qu’une méthode effectue un retour.

Suivre une exception sans gestionnaire correspondant

try {
    System.out.println("1");
    int[] values = new int[2];
    values[2] = 7;
    System.out.println("2");
} catch (NumberFormatException e) {
    System.out.println("3");
} finally {
    System.out.println("4");
}
System.out.println("5");

Seuls 1 et 4 s’affichent avant la propagation de l’ArrayIndexOutOfBoundsException. L’indice 2 est hors du tableau de deux éléments. Le gestionnaire ne correspond pas, mais finally s’exécute quand même. L’instruction qui affiche 5 se trouve hors du bloc de nettoyage : l’exception qui se propage la fait donc ignorer.

Si le travail protégé lève à la place une NumberFormatException correspondante après avoir affiché 1, le gestionnaire affiche 3, le nettoyage affiche 4 et l’exécution continue jusqu’à 5. Sur un chemin où tout réussit, aucun gestionnaire ne s’exécute, mais le nettoyage a quand même lieu.

Les valeurs de retour sont préparées avant le nettoyage

class Cleanup {
    static int result() {
        try {
            return 1;
        } finally {
            System.out.println("cleanup");
        }
    }
}

L’expression de retour est d’abord évaluée. Java affiche ensuite cleanup et l’appelant reçoit 1. Un break ou un continue qui quitte une région protégée exécute aussi son nettoyage avant que le transfert de contrôle prenne effet.

Ne place pas return dans finally. Un return 2; à cet endroit remplacerait la valeur de retour en attente et pourrait même écarter une exception en attente. Une exception levée par le nettoyage peut de la même façon remplacer l’échec d’origine. Le nettoyage ne doit pas introduire un second résultat concurrent. L’option -Xlint:finally du compilateur émet un avertissement lorsqu’un bloc finally ne peut pas se terminer normalement.

Fermer un objet uniquement s’il a été ouvert

L’ancien schéma manuel nécessite une variable visible par le bloc de nettoyage :

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Path;
import java.util.Scanner;

class ManualRead {
    static void firstLine(Path file) throws IOException {
        Scanner sc = null;
        try {
            sc = new Scanner(file, StandardCharsets.UTF_8);
            if (sc.hasNextLine()) System.out.println(sc.nextLine());
            if (sc.ioException() != null) throw sc.ioException();
        } finally {
            if (sc != null) sc.close();
        }
    }
}

Si l’ouverture échoue, sc vaut toujours null ; la condition empêche donc le nettoyage de lever une nouvelle exception de référence nulle. Pour les objets qui peuvent être fermés, l’instruction try avec gestion des ressources supprime ces tâches de suivi et gère plus sûrement les erreurs concurrentes.

finally ne garantit pas le nettoyage si la machine s’arrête. System.exit met fin à la JVM sans exécuter ce nettoyage ; un arrêt brutal ou une coupure de courant l’empêche aussi. Une boucle infinie qui ne quitte jamais le bloc n’atteint pas non plus son finally.

Tes méthodes peuvent rejeter des demandes invalides avant de modifier un objet. Choisis une exception qui indique le problème et permet à l’appelant d’y répondre.

Lever un objet immédiatement

class Percentage {
    private int value;

    public void setPercentage(int value) {
        if (value < 0 || value > 100) {
            throw new IllegalArgumentException(
                "percentage must be 0 to 100, was " + value);
        }
        this.value = value;
    }
}

L’appel setPercentage(120) lève une exception avec le message percentage must be 0 to 100, was 120. L’affectation n’a pas été exécutée, donc le champ conserve sa valeur précédente. C’est l’échec immédiat : signale la demande invalide à l’endroit où tu peux l’expliquer. La même vérification dans un constructeur empêche le renvoi d’un objet invalide.

throw exige un objet exception, comme dans throw new IllegalArgumentException("bad quantity");. Un nom de classe seul n’est pas un objet. Une instruction ordinaire placée directement après un throw inconditionnel dans le même bloc est inaccessible.

Objects.requireNonNull(name, "name must not be null"), de java.util.Objects, permet de vérifier facilement qu’une référence n’est pas nulle. Le refus d’ajouter un article à une commande déjà envoyée est un problème d’état ; une quantité d’articles négative est un problème d’argument.

Déclarer ce qui peut sortir de la méthode

Une méthode auxiliaire de lecture de fichier peut déclarer l’erreur contrôlée qu’elle peut transmettre :

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.List;

class NameLoader {
    static List<String> loadNames(Path file) throws IOException {
        return Files.readAllLines(file);
    }
}

throw est une instruction exécutable. throws fait partie de la déclaration de méthode et indique aux appelants les erreurs contrôlées qu’ils doivent traiter. Il n’intercepte pas une erreur et ne permet pas à la méthode de continuer après celle-ci. Chaque appelant doit intercepter IOException ou la déclarer à son tour. Une clause catch peut aussi relancer le même objet avec throw e;.

Intercepte l’exception là où une réponse utile est possible. Une méthode auxiliaire ne peut généralement pas demander à l’utilisateur de choisir un autre fichier, mais main le peut. Afficher « erreur » et renvoyer une liste vide ferait confondre un fichier manquant avec un fichier réellement vide. Dans une petite expérience, main peut déclarer throws IOException ; un programme terminé gère les erreurs prévisibles avec des messages utiles. Les types non contrôlés peuvent être déclarés pour les documenter, même si le compilateur ne l’exige pas.

Respecter le contrat hérité

Si une interface déclare read() throws IOException, une méthode qui la redéfinit peut déclarer IOException, une sous-classe contrôlée plus spécifique ou aucune exception contrôlée. Elle ne peut pas élargir la déclaration à Exception. Elle peut déclarer des types non contrôlés. Une redéfinition de Object.toString() ne peut pas ajouter IOException, puisque la méthode héritée ne déclare aucune exception contrôlée. Les appels effectués par le type interface doivent toujours traiter l’IOException déclarée, même lorsqu’une implémentation n’en déclare aucune.

Une exception standard suffit souvent. Crée une classe personnalisée lorsque les appelants doivent reconnaître un problème propre au programme, comme un stock insuffisant ou un enregistrement de données mal formé, et y répondre différemment.

Choisir la superclasse avec soin

Étendre Exception crée une exception contrôlée. Étendre RuntimeException crée une exception non contrôlée. Choisis une exception contrôlée lorsque les appelants doivent prévoir une erreur du domaine après laquelle ils peuvent reprendre l’exécution ; choisis une exception non contrôlée pour une mauvaise utilisation ou un bogue de programmation.

class OutOfStockException extends Exception {
    public OutOfStockException(String message) {
        super(message);
    }
}

super(message) stocke le message dans le mécanisme d’exception hérité, donc getMessage() le renvoie. Par convention, le nom de la classe se termine par Exception. Des champs et des accesseurs supplémentaires peuvent exposer des détails structurés, comme les quantités demandée et disponible.

Laisser le stock inchangé après un échec

import java.util.HashMap;

class Inventory {
    private final HashMap<String, Integer> stock = new HashMap<>();

    Inventory() {
        stock.put("pens", 12);
    }

    void remove(String item, int quantity) throws OutOfStockException {
        if (quantity <= 0) {
            throw new IllegalArgumentException("quantity must be positive");
        }
        int available = stock.getOrDefault(item, 0);
        if (quantity > available) {
            throw new OutOfStockException("Requested " + quantity
                + " of " + item + ", only " + available + " in stock");
        }
        stock.put(item, available - quantity);
    }
}

Avec 12 stylos au départ, en retirer 5 en laisse 7. Une demande ultérieure de 10 lève une exception et il en reste 7, car la mise à jour intervient après toutes les vérifications. L’appelant doit gérer ou déclarer l’erreur contrôlée de stock ; l’erreur de quantité invalide est non contrôlée. Un programme qui doit répondre différemment à un article inconnu pourrait utiliser une UnknownItemException apparentée, les deux types propres au domaine ayant InventoryException comme classe de base.

Encapsuler sans perdre le problème d’origine

Une méthode d’analyse peut transformer une erreur de conversion de bas niveau en une erreur au niveau d’un enregistrement :

class InvalidRecordException extends Exception {
    public InvalidRecordException(String message) {
        super(message);
    }
    public InvalidRecordException(String message, Throwable cause) {
        super(message, cause);
    }
}

Dans la méthode d’analyse, un gestionnaire peut faire ceci :

catch (NumberFormatException e) {
    throw new InvalidRecordException(
        "Line 3: quantity is not a number: x", e);
}

L’exception qui encapsule l’autre donne à l’appelant une catégorie explicite et un numéro de ligne. Sa méthode getCause() renvoie la NumberFormatException d’origine et la trace affichée conserve une section Caused by:. Construire une nouvelle exception avec uniquement l’ancien message fait perdre l’objet d’origine et sa trace.

java.io.UncheckedIOException est une classe d’encapsulation non contrôlée fournie spécifiquement pour IOException. Ses constructeurs acceptent la cause, avec un message facultatif. Elle peut transmettre une erreur de fichier depuis une méthode redéfinie qui ne peut pas ajouter de déclaration d’exception contrôlée. L’encapsulation change le type que voit l’appelant ; elle ne répare pas le problème de fichier. Pour les décisions ordinaires dans une boucle, utilise des conditions et break, sans inventer d’exceptions pour le déroulement courant.

Un fichier stocke des octets, tandis que ton programme manipule des caractères et des nombres. Pour réussir une lecture, il faut le bon emplacement, le bon encodage de caractères et une convention claire pour les lignes et les nombres sous forme de texte.

Trouver l’emplacement réel

Un chemin relatif part du répertoire de travail du programme. Il ne part pas du dossier qui contient le code source. Un chemin absolu part de la racine du système de fichiers, comme /home/ana/data/scores.txt, ou de la racine d’un lecteur sous Windows.

Path file = Path.of("data", "scores.txt");
System.out.println(System.getProperty("user.dir"));
System.out.println(file.toAbsolutePath());
System.out.println(file.getFileName());

Importe java.nio.file.Path. Créer ce Path n’ouvre rien et ne vérifie aucune existence. toAbsolutePath() révèle où Java cherchera et getFileName() donne scores.txt. Un environnement de développement intégré utilise souvent le dossier du projet comme répertoire de travail. Les barres obliques dans "data/scores.txt" fonctionnent sur Windows, Linux et macOS. Dans un littéral de chemin Windows, les barres obliques inverses doivent être échappées, comme dans "C:\\data\\scores.txt". L’ancienne classe java.io.File représente aussi un emplacement ; convertis avec toPath() ou toFile().

Associer les octets aux caractères

UTF-8 encode tous les caractères Unicode. Les caractères latins de base occupent un octet ; les autres en occupent de deux à quatre. Le texte « café » contient quatre caractères mais cinq octets en UTF-8 car « é » en occupe deux. Lire ces octets comme de l’ISO-8859-1 peut produire « café ». Utilise l’encodage employé pour l’écriture.

Les méthodes de Files pour le texte utilisent UTF-8 par défaut. Des classes comme FileWriter et un scanner ouvert sans jeu de caractères utilisent le jeu de caractères par défaut, qui est devenu UTF-8 avec Java 18 ; les installations plus anciennes peuvent utiliser un autre encodage. StandardCharsets.UTF_8, de java.nio.charset, rend le choix explicite. Des octets invalides lus par Files.readAllLines produisent MalformedInputException, une sous-classe de IOException.

Lire les lignes sans conserver leurs fins

Avec un terminateur après chaque ligne, « a » et « b » nécessitent quatre octets avec des fins de ligne LF et six avec des fins de ligne CRLF. BufferedReader.readLine(), Files.readAllLines et Scanner.nextLine() retirent les fins de ligne reconnues. Découper une chaîne complète avec split("\n") laisse le \r de Windows ; la conversion de "12\r" avec parseInt échoue donc. Privilégie les méthodes de lecture de lignes ou supprime les caractères blancs autour du texte. System.lineSeparator() et le spécificateur de format %n produisent la fin de ligne du système courant.

Garder un format numérique cohérent dans les fichiers

Integer.parseInt accepte un entier sous forme de texte, sans séparateur décimal. Double.parseDouble("3.5") accepte un point ; Double.parseDouble("3,5") échoue. Ces méthodes d’analyse ignorent les paramètres régionaux. Les méthodes numériques de Scanner et le formatage décimal ordinaire suivent les paramètres régionaux : des paramètres allemands ou néerlandais peuvent donc attendre "3,5" et produire "3,50". Utilise scanner.useLocale(Locale.ROOT) et String.format(Locale.ROOT, "%.2f", value) pour des données dont le séparateur décimal est un point ; importe java.util.Locale.

Les emplacements introuvables produisent souvent NoSuchFileException avec Files ou Scanner(Path), tandis que les anciens constructeurs prenant un nom de fichier peuvent produire FileNotFoundException. Les erreurs d’autorisation peuvent produire AccessDeniedException. Ce sont des erreurs d’entrée-sortie contrôlées : une expression de chemin correcte ne suffit pas à les empêcher.

Un fichier ouvert utilise une ressource du système d’exploitation. Sa fermeture la libère et vide le tampon d’un objet d’écriture. Un oubli de fermeture peut épuiser la limite de fichiers ouverts, faire perdre du texte en attente dans un tampon ou empêcher un autre programme de modifier le fichier.

Déclarer les ressources dans l’en-tête de try

import java.io.BufferedReader;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;

class Lines {
    static void show(Path file) throws IOException {
        try (BufferedReader in =
                Files.newBufferedReader(file, StandardCharsets.UTF_8)) {
            String line;
            while ((line = in.readLine()) != null) {
                System.out.println(line);
            }
        }
    }
}

L’en-tête ouvre le lecteur. Le corps l’utilise et Java le ferme lorsque le corps se termine normalement, effectue un retour ou lève une exception. Aucun finally séparé n’est nécessaire. Il n’y a pas de gestionnaire ici, donc toute erreur contrôlée est toujours transmise à l’appelant par throws IOException.

Une ressource doit implémenter AutoCloseable. Cette interface déclare close() et autorise Exception ; sa sous-interface Closeable restreint l’erreur contrôlée déclarée à IOException. Les lecteurs, les objets d’écriture et Scanner remplissent cette condition. Une String ne la remplit pas. Les variables de l’en-tête sont implicitement finales et disponibles dans le corps, mais pas dans les blocs catch ou finally de cette instruction. Java 9 et les versions ultérieures autorisent aussi une variable existante finale ou effectivement finale : try (in) { ... }.

Fermer dans l’ordre inverse

Sépare les ressources par des points-virgules :

try (BufferedReader in = Files.newBufferedReader(source);
     java.io.BufferedWriter out = Files.newBufferedWriter(target)) {
    String line;
    while ((line = in.readLine()) != null) {
        out.write(line);
        out.newLine();
    }
}

Il s’agit d’un bloc dans une méthode qui déclare IOException, avec des chemins source et target distincts. Java ouvre d’abord in, puis out, et ferme out avant in. Si l’ouverture de out échoue, le lecteur déjà ouvert est tout de même fermé. Ouvrir un objet d’écriture sur le chemin d’entrée tronquerait cette entrée ; les chemins doivent donc différer pour cette copie directe.

La fermeture des ressources a lieu avant les clauses catch et finally appartenant à la même instruction. Ces gestionnaires peuvent recevoir les erreurs provenant de l’ouverture, de l’utilisation ou de la fermeture des ressources.

Garder l’erreur principale visible

Supposons que le corps lève une exception d’enregistrement, puis que la fermeture du lecteur lève une IOException. L’instruction try avec gestion des ressources propage l’exception du corps et lui rattache l’erreur de fermeture comme exception supprimée. getSuppressed() permet de la récupérer et la trace affiche une section Suppressed:. L’erreur d’origine du corps reste visible. Si le corps réussit et que seule la fermeture échoue, l’exception de fermeture se propage normalement.

Si plusieurs erreurs se produisent pendant la fermeture, Java tente quand même les fermetures restantes. Un simple finally { resource.close(); } peut au contraire remplacer une erreur du corps en attente par une erreur de nettoyage.

Utilise ce schéma pour les ressources de fichiers dont ton code est responsable. Fermer un scanner sur System.in ferme aussi l’entrée clavier du programme, empêchant les lectures ultérieures. Garde plutôt la responsabilité de l’entrée standard partagée au niveau du programme au lieu de la fermer dans une méthode auxiliaire.

La lecture te donne du texte. L’analyse donne un sens à ce texte : un effectif, un âge ou un objet. Sépare ces deux opérations afin qu’un enregistrement incorrect ne ressemble pas à une erreur de lecture du fichier.

Choisir la quantité à conserver en mémoire

Importe java.nio.file.Files et Path, ainsi que les types de lecteurs ou de collections que tu utilises. Les méthodes de Files pour le texte utilisent UTF-8 par défaut. Un BufferedReader doit être placé dans une instruction try avec gestion des ressources et signale les erreurs de lecture avec IOException. Lire une ligne à la fois évite de conserver toute l’entrée en mémoire, sauf si ton traitement stocke ensuite tous les enregistrements.

Un scanner doit aussi être fermé et nécessite une vérification d’erreur supplémentaire :

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Path;
import java.util.Scanner;

class ScanFile {
    static void show(Path file) throws IOException {
        try (Scanner sc = new Scanner(file, StandardCharsets.UTF_8)) {
            while (sc.hasNextLine()) {
                System.out.println(sc.nextLine());
            }
            if (sc.ioException() != null) throw sc.ioException();
        }
    }
}

L’ouverture peut lever directement une exception. Pendant la lecture, Scanner traite une erreur d’entrée-sortie sous-jacente comme une fin d’entrée et l’enregistre ; ioException() permet de la récupérer. Sans cette vérification finale, une lecture partielle peut sembler réussie.

Compter les lignes physiques, puis analyser

Pour les lignes d’entrée "12", "15", "abc", une ligne vide et "9", incrémente le numéro de ligne avant de décider d’ignorer une ligne blanche. Convertis chaque ligne non blanche avec Integer.parseInt(line.trim()) dans son propre try. Signale "Line 3: not a number: abc" et continue. La somme des valeurs valides est de 36 et leur effectif est de 3, ce qui donne une moyenne de 12,0. Calcule (double) sum / count pour conserver une éventuelle partie fractionnaire et vérifie d’abord que l’effectif n’est pas nul.

Vérifier les champs avant d’utiliser leurs indices

Des données simples séparées par des virgules peuvent devenir des objets. Ici, la première ligne est un en-tête obligatoire ; chaque enregistrement suivant contient un nom non vide et un âge entier :

String[] parts = line.split(",", -1);
if (parts.length != 2 || parts[0].isBlank() || parts[1].isBlank()) {
    System.out.println("Line " + lineNumber + ": expected name and age");
    continue;
}
try {
    int age = Integer.parseInt(parts[1].trim());
    people.add(new Person(parts[0].trim(), age));
} catch (NumberFormatException e) {
    System.out.println("Line " + lineNumber + ": invalid age");
}

Ce fragment de corps de boucle suppose l’existence de line, lineNumber, d’une List<Person> nommée people et d’un constructeur Person(String, int). Ignore l’en-tête "name,age" avant cette étape d’analyse ; sinon, la conversion numérique de "age" échoue. Les enregistrements "Ana,34", "Ben,29" et "Chen,41" totalisent 104 ans et donnent une moyenne d’environ 34,67.

Un simple split(",") supprime les champs vides en fin de ligne : "Eve," ne produit qu’un seul élément. La limite -1 conserve le deuxième champ vide afin que la validation puisse le signaler. Vérifie toujours la longueur avant parts[1]. Le seul découpage ne traite pas les virgules entre guillemets, comme celle du nom dans ""Smith, Ana",34" ; le CSV complet nécessite un analyseur CSV.

Ouvrir un fichier de sortie peut le modifier immédiatement. Choisis entre remplacer son contenu et ajouter du texte à la fin avant d’ouvrir l’objet d’écriture, puis termine en le fermant pour que le texte en attente dans le tampon ne reste pas en mémoire.

Remplacer ou ajouter à la fin

Files.writeString(path, text) écrit une chaîne. Files.write(path, lines) écrit un ensemble de lignes parcourable, en ajoutant le séparateur de ligne du système après chacune, y compris la dernière. Avec leurs options par défaut, les deux créent un fichier manquant et tronquent un fichier existant.

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;

class RunLog {
    static void recordStart(Path log) throws IOException {
        Files.writeString(log, "started" + System.lineSeparator(),
            StandardCharsets.UTF_8,
            StandardOpenOption.CREATE, StandardOpenOption.APPEND);
    }
}

CREATE permet de créer un fichier ; APPEND conserve l’ancien contenu et ajoute du texte à la fin. APPEND seul échoue si le fichier est absent. L’ajout n’insère pas de séparateur manquant avant ton texte : si un fichier existant se termine au milieu d’une ligne, les caractères suivants prolongent cette ligne.

L’ancienne classe FileWriter possède un indicateur d’ajout : new FileWriter("log.txt", StandardCharsets.UTF_8, true). Sans ajout en fin de fichier, un nouveau FileWriter ou un PrintWriter ouvert par nom de fichier tronque aussi un fichier existant. N’ouvre jamais un objet d’écriture qui remplace le contenu sur une entrée que tu dois encore lire.

Choisir un objet d’écriture et repérer les erreurs

BufferedWriter prend en charge write et newLine(), et signale les erreurs d’écriture sous forme d’exceptions contrôlées :

import java.io.BufferedWriter;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.Locale;

class ReportWriter {
    static void write(Path file) throws IOException {
        try (BufferedWriter out =
                Files.newBufferedWriter(file, StandardCharsets.UTF_8)) {
            out.write("Readings: 3");
            out.newLine();
            out.write(String.format(Locale.ROOT, "Average: %.2f", 3.0));
            out.newLine();
        }
    }
}

Le fichier contient deux lignes : "Readings: 3" et "Average: 3.00". Locale.ROOT impose le point décimal. newLine(), println et %n utilisent tous la fin de ligne du système ; un \n littéral écrit LF sur tous les systèmes.

Un PrintWriter propose les méthodes pratiques print, println et printf, mais celles-ci enregistrent les erreurs d’entrée-sortie au lieu de les lever. checkError() vide le tampon et indique l’état de son indicateur d’erreur. Pour vérifier aussi les erreurs de fermeture finale, conserve l’accès à l’objet d’écriture et vérifie après sa fermeture. Pour un code qui doit propager les erreurs d’écriture de manière fiable, utilise BufferedWriter ou les méthodes Files.

Compléter le cycle

Les objets d’écriture mettent la sortie en tampon. flush() transmet le texte en attente ; close() vide le tampon et libère le fichier. L’instruction try avec gestion des ressources garantit qu’une fermeture est tentée à chaque sortie, mais ne peut pas garantir la réussite d’une écriture sur disque.

Pour enregistrer une personne, écris son nom, une virgule et son âge entier, puis une fin de ligne. Formate les nombres décimaux avec Locale.ROOT pour qu’un appel ultérieur à Double.parseDouble puisse les lire. L’ouverture d’un fichier ne crée pas un répertoire parent manquant : utilise Files.createDirectories(folder) lorsque sa création est voulue, ou signale l’échec. Une écriture peut échouer après une troncation ou une sortie partielle ; utilise un fichier temporaire et un déplacement atomique lorsque la destination doit être protégée.

Un programme robuste de traitement de fichiers doit gérer les erreurs à deux niveaux. Un enregistrement incorrect peut être ignoré et signalé ; une erreur de lecture ou d’enregistrement du fichier arrête la tâche. Calcule un résultat complet avant de toucher à sa destination.

Lire, valider, calculer, enregistrer

Le programme complet ci-dessous lit un en-tête facultatif "date,temperature" suivi d’enregistrements simples à deux champs. Les dates sont des indications non vides ; les températures sont des nombres finis en degrés Celsius. Il ignore et signale les enregistrements mal formés, y compris les lignes vides. L’exception contrôlée imbriquée sépare les problèmes d’enregistrement des problèmes de fichier.

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.AtomicMoveNotSupportedException;
import java.nio.file.Files;
import java.nio.file.NoSuchFileException;
import java.nio.file.Path;
import java.nio.file.StandardCopyOption;
import java.util.List;
import java.util.Locale;

public class TemperatureReport {
    static class InvalidRecordException extends Exception {
        InvalidRecordException(String message) { super(message); }
        InvalidRecordException(String message, Throwable cause) {
            super(message, cause);
        }
    }

    static List<String> readLines(Path file) throws IOException {
        return Files.readAllLines(file, StandardCharsets.UTF_8);
    }

    static double parseTemperature(String line, int lineNumber)
            throws InvalidRecordException {
        String[] parts = line.split(",", -1);
        if (parts.length != 2 || parts[0].isBlank()
                || parts[1].isBlank()) {
            throw new InvalidRecordException("Line " + lineNumber
                + ": expected a date label and a temperature");
        }
        try {
            double value = Double.parseDouble(parts[1].trim());
            if (!Double.isFinite(value)) {
                throw new InvalidRecordException("Line " + lineNumber
                    + ": temperature must be finite");
            }
            return value;
        } catch (NumberFormatException e) {
            throw new InvalidRecordException("Line " + lineNumber
                + ": not a number: " + parts[1], e);
        }
    }

    static String summarize(List<String> lines) {
        int count = 0;
        int skipped = 0;
        double sum = 0;
        double min = Double.POSITIVE_INFINITY;
        double max = Double.NEGATIVE_INFINITY;
        for (int i = 0; i < lines.size(); i++) {
            String line = lines.get(i);
            if (i == 0 && line.equals("date,temperature")) continue;
            try {
                double value = parseTemperature(line, i + 1);
                sum += value;
                count++;
                min = Math.min(min, value);
                max = Math.max(max, value);
            } catch (InvalidRecordException e) {
                skipped++;
                System.err.println(e.getMessage());
            }
        }
        if (count == 0) {
            return String.format(Locale.ROOT,
                "No valid readings%nSkipped lines: %d%n", skipped);
        }
        return String.format(Locale.ROOT,
            "Valid readings: %d%nAverage (°C): %.2f%n"
                + "Minimum (°C): %.2f%nMaximum (°C): %.2f%n"
                + "Skipped lines: %d%n",
            count, sum / count, min, max, skipped);
    }

    static void writeSummary(Path file, String text) throws IOException {
        Path target = file.toAbsolutePath();
        Path temp = Files.createTempFile(target.getParent(), "report-", ".tmp");
        try {
            Files.writeString(temp, text, StandardCharsets.UTF_8);
            Files.move(temp, target, StandardCopyOption.ATOMIC_MOVE);
        } catch (IOException e) {
            try {
                Files.deleteIfExists(temp);
            } catch (IOException cleanup) {
                e.addSuppressed(cleanup);
            }
            throw e;
        }
    }

    public static void main(String[] args) {
        Path input = Path.of("readings.csv");
        Path output = Path.of("summary.txt");
        try {
            List<String> lines = readLines(input);
            String report = summarize(lines);
            writeSummary(output, report);
            System.out.println("Saved: " + output.toAbsolutePath());
        } catch (NoSuchFileException e) {
            System.err.println("File or folder not found: " + e.getFile());
        } catch (AtomicMoveNotSupportedException e) {
            System.err.println("Could not save atomically: "
                + output.toAbsolutePath());
        } catch (IOException e) {
            System.err.println("Could not process " + input.toAbsolutePath()
                + " or save " + output.toAbsolutePath() + ": " + e.getMessage());
        }
    }
}

Suivre une exécution

Utilise ces cinq lignes d’entrée sans en-tête :

2026-03-01,4.5
2026-03-02,6.0
2026-03-03,abc
2026-03-04,-1.5
missing comma

Les lignes 1, 2 et 4 produisent trois mesures valides. La somme est de 9,0 ; la moyenne est de 3,00 °C, le minimum de -1,50 °C et le maximum de 6,00 °C. Les lignes 3 et 5 produisent des diagnostics et le rapport indique deux lignes ignorées. Le gestionnaire d’analyse se trouve dans la boucle, donc chaque enregistrement incorrect laisse les enregistrements suivants accessibles. Mettre à jour les sommes uniquement après une analyse réussie empêche l’intégration des valeurs rejetées.

Double.parseDouble accepte des chaînes particulières comme "NaN" et "Infinity". Double.isFinite les rejette ici car elles ne peuvent pas servir de températures mesurées ordinaires. Un fichier vide, un fichier ne contenant que l’en-tête ou des enregistrements tous invalides conduisent à la branche où l’effectif est nul, avant la division ou l’utilisation du minimum et du maximum initiaux.

Protéger la destination

La lecture et le calcul se terminent avant le début de l’enregistrement. Files.writeString ouvre et ferme son propre fichier, mais peut échouer après en avoir écrit une partie. Le programme écrit donc dans un fichier temporaire du dossier de destination, le ferme et demande ATOMIC_MOVE. Lorsque cette opération est prise en charge, le déplacement rend le résultat terminé visible en une seule opération du système de fichiers.

Le remplacement atomique d’une cible existante dépend de l’implémentation. Le programme signale tout déplacement ou remplacement non pris en charge et ne réessaie jamais avec un déplacement non atomique. Une erreur de nettoyage est rattachée à l’exception d’origine au lieu de la remplacer. La visibilité atomique ne garantit pas la conservation des données en cas de coupure de courant.

Vérifier Files.exists(input) au préalable ne peut pas garantir la lecture ultérieure : un fichier peut disparaître ou devenir inaccessible après la vérification. Gère l’opération elle-même. Avant de te fier à un programme de traitement, essaie une entrée manquante, des dossiers de sortie manquants, des fichiers vides ou ne contenant que l’en-tête, des fins de ligne CRLF, du texte accentué et des enregistrements mal formés. Les messages destinés à l’utilisateur doivent nommer le chemin concerné ; pour déboguer une exception qui en encapsule une autre, il faut aussi sa cause d’origine et sa trace de pile.