Discussion :

[austin57]

Bonjour à tous,

Et désolé pour le drôle de titre. Sur un poste précédent j'étais en train de regarder le fonctionnement des exceptions. Et en continuant mes tests sur Java, je suis arrivé à ce code.

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
package fr.test.serialisation;
 
import java.io.EOFException;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
 
public class Deserialisation {
 
 
	public static void deser() {
	File file = new File("test2.ser");
 
	try (FileInputStream fis = new FileInputStream(file);
			ObjectInputStream ois = new ObjectInputStream(fis)) {
 
// La bonne méthode?
		while (fis.available()>0) {
			System.out.println(ois.readObject());
		}
 
//		Variante sauvage avec une belle boucle infinie ? Mais on s'en fout, c'est certain que ça va lever une exception EOFException
//		while (true) {
//			System.out.println(ois.readObject());
//		}
 
 
	} catch (EOFException e) {
			System.out.println(e.getMessage());
	} catch (ClassNotFoundException | IOException e) {
			e.printStackTrace();
	}
 
	}
}

Au départ, je ne savais pas utiliser la fonction .available() d'un objet FileInputStream. Du coup, j'en été arrivé à la solution sauvage qui consiste à dire que j'arriverai obligatoirement à extraire l'ensemble des éléments de mon FileInputStream pour terminer sur une erreur (d'où la boucle infinie qui attends en réalité une exception). Alors, plutôt que de me casser la tête, pourquoi ne pas gérer l'erreur EOFException.

Est-ce une pratique standard en programmation, voir une bonne pratique ? Car je me dis que gérer une exception, c'est quand même plus facile que de faire 36 vérifications préalables. Par exemple, si je veux ouvrir un fichier, je pense qu'il y a deux façons de procéder:
1- La prudente : Je vérifie que le fichier est présent, que j'ai les permissions suffisantes, qu'il n'est pas déjà ouvert,..., si toutes mes vérifs sont ok, je peux ouvrir et écrire mon fichier.
2 - La téméraire : Je tente direct d'ouvrir et d'écrire mon fichier sans vérification, si ça plante, c'est que c'était pas bon.
Bon, avec mes 3 semaines d'expérience en Java, forcément, c'est peut-être un peu simple. Mais je me dis qu'il est parfois plus aisé de tenter directement quelque chose et de gérer un échec potentiel. Que l'inverse, c'est à dire faire pleins de contrôle préalable...pour au final, peut-être devoir gérer un échec.

C'est un point de détail mais j'aurai bien aimé avoir l'avis de personnes aguerries.
Merci d'avance.
Damien

[tchize_]

Code :

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

1
2
3
 
// La bonne méthode?
		while (fis.available()>0) {

Non, le fileinpustream est manipulé par l'objectinputstream qui peut potentiellement faire du buffering. Du coup le stream fichier peut être arrivé à la fin alors qu'il reste des objets à lire

j'arriverai obligatoirement à extraire l'ensemble des éléments de mon FileInputStream pour terminer sur une erreur (d'où la boucle infinie qui attends en réalité une exception). Alors, plutôt que de me casser la tête, pourquoi ne pas gérer l'erreur EOFException.

readObject ne déclarer pas retourner EOFException. Tu ne devrais te concentrer que sur les exceptions officiellement déclarée. Toutes les autres sont des effets de bords du stream sous jacent.

Est-ce une pratique standard en programmation, voir une bonne pratique ? Car je me dis que gérer une exception, c'est quand même plus facile que de faire 36 vérifications préalables. Par exemple, si je veux ouvrir un fichier, je pense qu'il y a deux façons de procéder:

Ca va dépendre de ce que tu fais. Il est courant effectivement de tenter l'opération pour ensuitre retomber sur ses pattes si elle échoue. Cela principalement car il n'est pas toujours possible de déterminer toutes les critères de réalisation de la méthode. En général on préfère un test simple à une exception car une exception c'est lourd à lancer pour la VM. Il faut donc raison garder. Pour te donner deux extrèmes:

je vais préférer faire un test avec " == null" sur le nom d'un fichier plutot que de catcher une NullPointerException. Le test est simple.
je vais préférer catcher un SQLException sur un insertion plutot que de vérouiller la DB et de tenter de déterminer si l'insert peut avoir lieu avec certitude. Le test est compliqué à écrire et peu probant.

[adiGuba]

Salut,

Non, le fileinpustream est manipulé par l'objectinputstream qui peut potentiellement faire du buffering. Du coup le stream fichier peut être arrivé à la fin alors qu'il reste des objets à lire

+1 : lorsqu'on englobe des flux il faut éviter d'utiliser directement des méthodes de l'instance englobé car tu risques d'avoir un comportement incohérent.
=> Il faudrait utiliser available() sur l'ObjectInputStream...

Mais même là je le déconseillerais : la méthode available() ne renvoi pas le nombre d'octet restant, mais le nombre d'octet lisible sans que cela ne provoque une interruption I/O.
Bref cela pourrait très bien te retourner "0" même s'il reste des données dans le flux...



Sinon plutôt que d'attendre un EOFException, il serait préférable d'utiliser un format plus précis pour ton fichier sérialisé.
Par exemple en sérialisant un tableau (ou une List) contenant tout tes objets, voir une classe spécifique contenant les divers objets de ton flux...

Ainsi tu n'a qu'un seul object à lire/écrire quoi qu'il arrive, et tu peux même partager le code de lecture/écriture.


a++

[austin57]

Bonjour et merci pour vos réponses.

Voilà matière me permettant de répondre à mes interrogations.
Je trouve cela vraiment intéressant. Je vais suivre vos conseils pour modifier mon code en conséquence.
Et garder en mémoire ce post pour mes développements futurs. Et ça tombe bien, je viens juste de voir comment sérialiser un ArrayList^^.

Damien.