ObjectInputStream : test d'arrêt EOF?

Version imprimable

Salut,

Comment faire pour lire un fichier jusqu'au bout en récupérant les objets qui sont dedans, en s'arrêtant proprement?

Je n'ai pas trouvé d'autres solutions que de faire ça, ce qui ne me convient absolument pas (un while(true) pour une boucle non infinie, je n'aime pas):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
    try {
        ObjectInputStream ois = new ObjectInputStream(new FileInputStream(filename));
        try {
            while(true) {
                try {
                    Object read = ois.readObject();
                    ...
                } catch(ObjectStreamException ose) {} catch(ClassNotFoundException cnfe) {}
            }
        } catch(EOFException oef) { /* pour sortir de la boucle */ }
 
    } catch(FileNotFoundException fnfe) { ... } catch(IOException ioe) { ... }

Tu peux utiliser la méthode available() de ton ObjectInputStream.
Au passage, n'oublie pas de fermer le flux dans un bloc finally ;)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
try {
    ObjectInputStream ois = new ObjectInputStream(new FileInputStream(filename));
    try {
        while(ois.available() > 0) {
             try {
                Object read = ois.readObject();
                ...
             } catch(ObjectStreamException ose) {}
             catch(ClassNotFoundException cnfe) {}
    } finally {
         ois.close();
    }     
} catch(FileNotFoundException fnfe) { 
       ... 
} catch(IOException ioe) { 
       ... 
}

Merci, je vais essayer ça :)

Pour le bloc finally, c un peu bête que le close puisse lever une IOException:

Code:

1
2
3
4
5
6
7
        finally {
            if(oos != null) {
                try {
                    oos.close();
                } catch(IOException ioe) {}
            }
        }

28/07/2006, 15h48
®om

et dans le cas du while(ois.available() > 0), il faut tester quand même EOFException (on peut arriver à la fin du fichier avant la fin de chargement d'un objet si le fichier est corrompu)?

EDIT: J'ai rien dit, FileNotFoundException < IOException :)

Salut,

Citation:

Envoyé par le y@m's

Tu peux utiliser la méthode available() de ton ObjectInputStream.

Attention car la valeur renvoyé par available renvoit le nombre de byte disponible sans que la méthode read() ne soit bloqué... mais cela ne veut pas forcément dire que l'on a atteint la fin du flux...

Citation:

Envoyé par le y@m's

Au passage, n'oublie pas de fermer le flux dans un bloc finally ;)

+1

Et pas de catch() vide !!!! J'espère que ce n'est pas le cas dans le vrai code ;)

Sinon pour revenir à ton problème, tu peux utiliser un booleen qui contient le status EOF, par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 try { FileInputStream fis = new FileInputStream(filename); try { ObjectInputStream ois = new ObjectInputStream(fis); try { boolean hasObject = true; while(hasObject) { try { Object read = ois.readObject(); // ... } catch(EOFException oef) { hasObject = false; } } } finally { ois.close(); } } finally { fis.close(); } } catch(IOException e) { e.printStackTrace(); } // etc...
Sinon pourquoi ne pas serialiser un tableau ou une List qui contiendrait tout le contenu ? Tu n'aurais alors qu'un seul readObject à lire...

Citation:

Envoyé par ®om

Pour le bloc finally, c un peu bête que le close puisse lever une IOException:

Il vaut mieux utiliser un try/finally à l'intérieur du try/catch plutôt que de faire un try/catch/finally : http://www.developpez.net/forums/sho...4&postcount=69

a++

28/07/2006, 15h57
®om

Citation:

Envoyé par le y@m's

Tu peux utiliser la méthode available() de ton ObjectInputStream.

Ca ne marche pas, ça me renvoie 0, alors que si je fais la boucle while(true) il y a bien qqch à lire...

Citation:

Envoyé par adiGuba

Et pas de catch() vide !!!! J'espère que ce n'est pas le cas dans le vrai code ;)

Non non t'inquiète :)

Citation:

Envoyé par adiGuba

Sinon pourquoi ne pas serialiser un tableau ou une List qui contiendrait tout le contenu ? Tu n'aurais alors qu'un seul readObject à lire...

Parce qu'en fait c'est pour sauver l'ensemble des configurations des modules... même celles que peuvent rajouter les plug-ins... Et si une renvoie un "NotSerializableException", rien ne se chargerait, alors que là on peut quand même changer les autres :)

Citation:

Envoyé par adiGuba

Il vaut mieux utiliser un try/finally à l'intérieur du try/catch plutôt que de faire un try/catch/finally : http://www.developpez.net/forums/sho...4&postcount=69

Mouais, mais je ne trouve pas, car les actions que l'on fait sur le catch(IOException) ne sont pas forcément les mêmes que si le .close() échoue...

Voici ce que donne ma méthode maintenant:

Code:

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
37
38
39
40
41
42
43
44
45
46
47
    /**
     * Charge les configurations actuelles à partir du fichier de configuration.
     */
    public synchronized void load() {
        if(ModuleLoader.getModuleLoader().loadingIsComplete())
            throw new UnsupportedOperationException("Impossible de lancer un nouveau chargement.");
 
        assert map.isEmpty() : "Aucune configuration ne doit être déjà présente.";
 
        ObjectInputStream ois = null;
        try {
            ois = new ObjectInputStream(new FileInputStream(configFilename));
 
            /* Indique s'il reste des objets à lire. */
            boolean hasObject = true;
 
            do {
                try {
                    Object read = ois.readObject();
                    if(read instanceof Configuration) {
                        Configuration config = (Configuration) read;
                        ModuleLoader.getModuleLoader().log("Chargement de la configuration " + config.getId() + "...");
                        register(config);
                    } else {
                        Logger.getLogger("MyFreeTV").severe("Un objet du fichier de configuration n'est pas une configuration.");
                    }
                } catch(EOFException oef) {
                    hasObject = false;
                } catch(ObjectStreamException ose) {
                    Logger.getLogger("MyFreeTV").severe("Une configuration n'a pas pu être chargée (erreur d'I/O).");
                } catch(ClassNotFoundException cnfe) {
                    Logger.getLogger("MyFreeTV").severe("Une configuration n'a pas pu être chargée (classe non trouvée).");
                }
            } while(!hasObject);
 
        } catch(FileNotFoundException fnfe) {
            /* Le fichier n'existe pas... ce qui est normal lors du premier chargement du programme. */
        } catch(IOException ioe) {
            Logger.getLogger("MyFreeTV").severe("Erreur d'I/O dans le fichier de configuration.");
        } finally {
            if(ois != null) {
                try {
                    ois.close();
                } catch(IOException ioe) {}
            }
        }
    }

28/07/2006, 16h23
adiGuba

Citation:

Envoyé par ®om

Non non t'inquiète :)

AAh je suis rassuré :mrgreen:

Citation:

Envoyé par ®om

Parce qu'en fait c'est pour sauver l'ensemble des configurations des modules... même celles que peuvent rajouter les plug-ins... Et si une renvoie un "NotSerializableException", rien ne se chargerait, alors que là on peut quand même changer les autres :)

En effet c'est une bonne raison :mrgreen:

Citation:

Envoyé par ®om

Mouais, mais je ne trouve pas, car les actions que l'on fait sur le catch(IOException) ne sont pas forcément les mêmes que si le .close() échoue...

Mouais... je n'ai jamais vraiment eu le cas...
Et je ne pense pas que ce soit génant dans ton cas de loggé les erreurs qui pourrait survenir à la fermeture... surtout qu'elle ne sont pas vraiment fréquente...

Enfin, et parce que je suis très chiant :twisted: : il y a un cas où tu ne fermes pas correctement le fichier !
En effet comme le constructeur d'ObjectInputStream commence à lire le flux pour vérifier qu'il s'agit bien d'un fichier sérialisé, tu peux avoir une StreamCorruptedException...

Donc dans le cas où le fichier ouvert n'est pas correct, la référence ois est null car le constructeur aura généré une exception, et tu n'appelles pas le close() (normal). Or tu as ouvert un FileInputStream qui ne sera pas fermé, et dont tu auras perdu la référence...

hé hé hé hé :mouarf: (je sais je suis sadique !)

a++

Citation:

Envoyé par adiGuba

Enfin, et parce que je suis très chiant :twisted: : il y a un cas où tu ne fermes pas correctement le fichier !
En effet comme le constructeur d'ObjectInputStream commence à lire le flux pour vérifier qu'il s'agit bien d'un fichier sérialisé, tu peux avoir une StreamCorruptedException...

Donc dans le cas où le fichier ouvert n'est pas correct, la référence ois est null car le constructeur aura généré une exception, et tu n'appelles pas le close() (normal). Or tu as ouvert un FileInputStream qui ne sera pas fermé, et dont tu auras perdu la référence...

hé hé hé hé :mouarf: (je sais je suis sadique !)

Bien vu !!

C'est mieux comme ça?

Code:

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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
    /**
     * Charge les configurations actuelle à partir du fichier de configuration.
     */
    public synchronized void load() {
        if(ModuleLoader.getModuleLoader().loadingIsComplete())
            throw new UnsupportedOperationException("Impossible de lancer un nouveau chargement.");
 
        assert map.isEmpty() : "Aucune configuration ne doit être déjà présente.";
 
        ObjectInputStream ois = null;
        FileInputStream fis = null;
        try {
            fis = new FileInputStream(configFilename);
            ois = new ObjectInputStream(fis);
 
            /* Indique s'il reste des objets à lire. */
            boolean hasObject = true;
 
            do {
                try {
                    Object read = ois.readObject();
                    if(read instanceof Configuration) {
                        Configuration config = (Configuration) read;
                        ModuleLoader.getModuleLoader().log("Chargement de la configuration " + config.getId() + "...");
                        register(config);
                    } else {
                        Logger.getLogger("MyFreeTV").severe("Un objet du fichier de configuration n'est pas une configuration.");
                    }
                } catch(EOFException oef) {
                    hasObject = false;
                } catch(ObjectStreamException ose) {
                    Logger.getLogger("MyFreeTV").severe("Une configuration n'a pas pu être chargée (erreur d'I/O).");
                } catch(ClassNotFoundException cnfe) {
                    Logger.getLogger("MyFreeTV").severe("Une configuration n'a pas pu être chargée (classe non trouvée).");
                }
            } while(!hasObject);
 
        } catch(FileNotFoundException fnfe) {
            /* Le fichier n'existe pas... ce qui est normal lors du premier chargement du programme. */
        } catch(IOException ioe) {
            Logger.getLogger("MyFreeTV").severe("Erreur d'I/O dans le fichier de configuration.");
        } finally {
            try {
                if(ois != null) {
                    ois.close();
                } else if(fis != null) {
                    fis.close();
                }
            } catch(IOException ioe) {}
        }
    }

28/07/2006, 16h31
adiGuba

Citation:

Envoyé par ®om

C'est mieux comme ça?

Oui :mrgreen:

Même si je n'aime pas vraiment les try/catch/finally :roll:

a++ ;)
28/07/2006, 16h34
®om

Citation:

Envoyé par ®om

Parce qu'en fait c'est pour sauver l'ensemble des configurations des modules... même celles que peuvent rajouter les plug-ins... Et si une renvoie un "NotSerializableException", rien ne se chargerait, alors que là on peut quand même changer les autres...

Mon exemple de "NotSerializableException" est mal choisi, pour un chargement c'est peu probable ^^
Bon on va dire "ClassNotFoundException", c'est plus cohérent :)
28/07/2006, 16h40
adiGuba

Citation:

Envoyé par ®om

Mon exemple de "NotSerializableException" est mal choisi, pour un chargement c'est peu probable ^^
Bon on va dire "ClassNotFoundException", c'est plus cohérent :)

J'avais compris cela pour la phase de sérialisation, où cela reste cohérent ;)

a++
28/07/2006, 16h44
®om

Citation:

Envoyé par adiGuba

J'avais compris cela pour la phase de sérialisation, où cela reste cohérent ;)

a++

Ah oui effectivement :D J'avais répondu dans ce sens aussi lol...
31/07/2006, 13h02
had35
Citation:

Envoyé par adiGuba

Enfin, et parce que je suis très chiant :twisted: : il y a un cas où tu ne fermes pas correctement le fichier !
En effet comme le constructeur d'ObjectInputStream commence à lire le flux pour vérifier qu'il s'agit bien d'un fichier sérialisé, tu peux avoir une StreamCorruptedException...

Donc dans le cas où le fichier ouvert n'est pas correct, la référence ois est null car le constructeur aura généré une exception, et tu n'appelles pas le close() (normal). Or tu as ouvert un FileInputStream qui ne sera pas fermé, et dont tu auras perdu la référence...

Salut,

En fait ça ne devrait pas poser de problème car ce n'est pas le constructeur qui retourne l'objet mais l'opérateur new. Cela signifie que même si le constructeur lève une exception avant que toutes ses instructions n'aient été exécutées, l'opérateur retournera quand même un objet, certes mal construit mais c'est suffisant pour que
Code:

1 2 ois =! null
renvoie la valeur true.

En revanche, il y a de fortes chances ensuite que
Code:

1 2 ois.close()
lève une exception.
31/07/2006, 13h09
adiGuba

Citation:

Envoyé par had35

En fait ça ne devrait pas poser de problème car ce n'est pas le constructeur qui retourne l'objet mais l'opérateur new. Cela signifie que même si le constructeur lève une exception avant que toutes ses instructions n'aient été exécutées, l'opérateur retournera quand même un objet,

Si une exception survient dans le constructeur, l'affectation de la référence n'est pas éffectué et on a bien une valeur null. Je ne pense pas que l'on puisse obtenir une référence invalide en Java...

a++

Citation:

Envoyé par adiGuba

Si une exception survient dans le constructeur, l'affectation de la référence n'est pas éffectué et on a bien une valeur null. Je ne pense pas que l'on puisse obtenir une référence invalide en Java...

a++

Ben en fait, on obtient un résultat bizarre. J'avais déjà testé cette situation et la référence est bien initialisée avec un objet. Mais seuls les attributs de l'objet qui ont pu être initialiés avant l'exception le sont, les autres sont à null où à leur valeur par défaut pour les primitives.

Par exemple :
Code:

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 class Exemple { String attribut1; String attribut2; Exemple() throws Exception { attribut1 = "initialisé"; if(value == null) throw new Exception(); attribut2 = "initialisé"; //attribut2 ne sera jamais initialisé } public static void main(String[] args) { //test Exemple ex; try { ex = new Exemple(); } catch(Exception e) { System.out.println(ex.toString()); System.out.println(ex.attribut1); //affiche initialisé System.out.println(ex.attribut2); //affiche null } } }
J'ai réédité le code pour gérer l'exception :oops:

Heu... ton code ne compile pas car ex n'est pas initialisé.

J'ai essayé avec ceci et ma référence ex reste à null :

Code:

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
class Exemple {
    String attribut1;

    String attribut2;

    Exemple() throws Exception {
        attribut1 = "initialisé";

        if (true) // Pour générer l'exception à tout les coups
            throw new Exception();

        attribut2 = "initialisé"; // attribut2 ne sera jamais initialisé
    }

    public static void main(String[] args) { // test
        Exemple ex = null;

        try {
            ex = new Exemple();
        } catch (Exception e) {
            System.out.println(ex.toString()); // NullPointerException
            System.out.println(ex.attribut1);
            System.out.println(ex.attribut2);
        }
    }
}

a++

Citation:

Envoyé par adiGuba

Heu... ton code ne compile pas car ex n'est pas initialisé.

J'ai essayé avec ceci et ma référence ex reste à null ...

Oui, en effet, je confonds :oops:
Pour rencontrer le cas que j'évoque, l'exception doit être attrapée dans le constructeur et non y est lancée :
Code:

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 class MiseEnOeuvre { String attribut1; Exemple attribut2; MiseEnOeuvre() { attribut1 = "initialisé"; try { attribut2= new Exemple(); } catch(Exception e) { System.out.println("construction de l'objet interrompu"); } } public static void main(String[] args) { // test MiseEnOeuvre ex = new MiseEnOeuvre(); System.out.println(ex.toString()); System.out.println(ex.attribut1);//affiche initialisé System.out.println(ex.attribut2); //affiche null } } class Exemple { Exemple() throws Exception { if (true) throw new Exception(); } }
(code testé ;) )

31/07/2006, 16h21
adiGuba

Citation:

Envoyé par had35

Pour rencontrer le cas que j'évoque, l'exception doit être attrapée dans le constructeur et non y est lancée :

Dans ce cas c'est tout à fait normal : tu n'affectes pas l'attribut attribut2 donc il prend sa valeur par défaut (null pour un Object)...

a++
31/07/2006, 16h42
had35

Par rapport au problème initial, il fallait donc bien garder une référence vers le flux de lecture pour être certain de pouvoir le refermer. :hola:
31/07/2006, 20h04
®om
Citation:
Envoyé par had35

Salut,

En fait ça ne devrait pas poser de problème car ce n'est pas le constructeur qui retourne l'objet mais l'opérateur new. Cela signifie que même si le constructeur lève une exception avant que toutes ses instructions n'aient été exécutées, l'opérateur retournera quand même un objet, certes mal construit mais c'est suffisant pour que

Code:

1 2 ois =! null

renvoie la valeur true.

En revanche, il y a de fortes chances ensuite que

Code:

1 2 ois.close()

lève une exception.
Je suis d'accord avec adiGuba, si le new InputStreamReader() lève une exception mais que le new FileReader() n'en lève pas, le FileReader est bien créé, même si aucune poignée ne permet d'y accéder, le flux n'est pas fermé...
31/07/2006, 20h52
adiGuba

Citation:

Envoyé par ®om

même si aucune poignée ne permet d'y accéder, le flux n'est pas fermé...

A nuancer toutefois : le flux sera fermé lorsque le GC désallouera la mémoire de l'objet via la méthode finalize() qui ferme le flux s'il n'a pas déjà été fermé (en tout cas dans les implémentations des principaux Stream et Reader de l'API)...

Mais ce n'est pas une raison suffisante pour ne pas les fermer, c'est juste un garde-fou ;)

a++