Salut,

Envoyé par
Napalm51
aller juste pour le "idéalement" car ça me perturbe :p (bah oui je tape 50x ces lignes par jour en ce moment)
Il y a juste un détail qui me gène dans ton code...
Non seulement tu as deux bloc de traitement pour les IOException (alors que le traitement est identique), mais ton code peut renvoyer une NullPointerException plutôt ennuyeuse à mon avis :

Si une erreur survient lors de l'ouverture du fichier (par exemple un FileNotFound car tu spécifies un répertoire inexistant), tu vas bien traiter l'exception dans le premier bloc catch, mais comme tu vas tenter d'exécuter le
finally juste après tu auras un
NullPointer sur les appels à
close() puisque les objets n'ont pas été créé...
Perso j'ai une petite préférence pour les try/finally imbriqué dans un try/catch :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
| try {
// Création du flux bufférisé sur un FileReader,
// immédiatement suivi par un try/finally, ce qui
// permet de ne fermer le flux QUE s'il le reader
// est correctement instancié (évite les NPE)
BufferedReader buff = new BufferedReader(new FileReader("g:\\fichier.txt"));
try {
String line;
// Lecture du fichier ligne par ligne. Cette boucle se termine
// quand la méthode retourne la valeur null.
while ((line = buff.readLine()) != null) {
System.out.println(line);
}
} finally {
// dans tous les cas, on ferme nos flux
buff.close();
}
} catch (IOException ioe) {
// erreur de fermeture des flux
System.out.println("Erreur --" + ioe.toString());
} |
- Si un exception survient pendant la création de l'objet, on remonte directement dans le catch sans passer par le finally.
- Si l'objet est bien créé on rentre dans le try/finally ce qui garantie que le close sera appelé dans tous les cas...
- Les éventuelles exceptions du close() seront traité dans le même bloc catch.
Même s'il y a quand même un point qui pourrait être problématique : si une exception survient pendant le close(), cela pourrait "cacher" une exception survenu dans le try/finally...
a++
Partager