Discussion :

[Clorish]

Hello,

Je me pose uen question metaphysique : Lorsqu'on manipule un fichier via les bufferwriter (par exemple) il faut encadrer son code par un try/catch avec une clause finally pour fermet le fichier (close). Or cette methode lance egalement une exception IOException.

Existe t il un moyen propre de gerer ca sans faire un 2e bloc try/catch dans le finally ... ce qui est assez hard en somme.

[adiGuba]

Salut,

Perso j'utilise plutôt un try/finally à l'intérieur d'un try/catch, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
	try {
		// Ouverture du fichier :
		BufferedWriter writer = new BufferedWriter(new FileWriter("..."));
		try {
			// Traitements sur le fichier...
			...
		} finally {
			// Fermeture du fichier.
			writer.close();
		}
 
	} catch (IOException e) {
		// Gestion de l'exception
		e.printStackTrace();
	}

On a une gestion commune de toutes les exceptions, et le scope de la variable "writer" est bien limité (pas besoin de la déclarer dans le bloc supérieur ni de la tester dans le finally).


J'y vois toutefois 2 défauts :

• Le double niveau de bloc (try/finally + try/catch) pas forcément très lisible (vivement les closures!)
• Si une exception survient dans le try/finally, on fait le close() avant le traitement de l'exception. Or le close() peut remonter une autre exception qui "cacherait" alors la première. Mais bon ce cas est toutefois assez rare...

a++

[CheryBen]

Salut, bouh! c'est dans la FAQ

Ca n'évite pas complètement les 2 blocs, c'est plutôt

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
try {
    try {
         fichier.write();
    }
    finally {
        fichier.close();
    }
}
catch(IOException e) {
    e.printstacktrace();
}

EDIT : grillé par adiGuba, la FAQ vivante

[Clorish]

Merci pour vos reponses ....
J'aurais justement voulu eviter les doubles blocs
Je trouve que le java deviens trop vite illisible .....

M'enfin bon on fera avec.
Quand aux closures a mon avis c'est pas pour tout de suite. deja que la ou je bosse ils en sont encore a la 1.4 .....

[gifffftane]

Je suis assez d'accord, cela conduit à un code assez lourd ; il me semble que le close aurait dû être protégé par une RuntimeException.

Moi, ma petite combine consiste à tout englober dans une méthode qui rejette les IOExceptions, tout en faisant le close dans un finally. Ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
void manipulation() throws IOException
{
 try
 {
  jeManipule();
 }
 finally
 {
  io.close();
 }
}

Mes 2 centimes.

[Patriarch24]

En utilisant l'API commons io d'apache, on écrit ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
InputStream in = null;
try {
    in = new BufferedInputStream(new FileInputStream(f));
    // utilise in
} catch (IOException e) {
    log.error(e);
} finally {
    IOUtils.closeQuietly(in); // ferme in sans exception !
}

[adiGuba]

En utilisant l'API commons io d'apache, le code devient :

Ben perso je trouve cela nettement moins propre : on ignore carrément une exception !

Et surtout avec un flux bufférisé comme ici !
les opérations d'écriture peuvent être effectuées réellement lors du close(), donc en cas de problème tu passerais carrément à coté !


a++

[Patriarch24]

Autant pour moi.

BufferedInputStream

Donc je suis hors sujet

[adiGuba]

Oui ici c'est un InputStream mais le problème est le même : tant que tu connais pas précisément l'implémentation des flux que tu manipules tu ne peux pas prédire les exceptions qui peuvent remonter (ou non) lors d'un close(), et tu risques donc d'ignorer une exception...


Je suis tout à fait d'accord qu'il s'agit de cas bien particulier qui arrivent rarement... mais le jour où ca arrive c'est pratique d'avoir un gestion propre des exception plutôt que de perdre un temps fou sur un problème apparemment inexplicable...


a++