Discussion :

[psykoprof]

Bonjour, je suis en train de faire quelques tests sur la gestion des exceptions et j'aimerais être sûr de faire les choses convenablement.

Le principe du programme est de lire des trames GPS contenues dans un fichier texte, de splitter ces trames pour en récupérer que quelques infos qui seront ensuite enregistrer dans un autre fichier texte.

J'aimerais savoir si je dois gérer absolument toutes les exceptions possibles (NullPointeurException, IOException, etc....) ?
Comment exploiter proprement la fermeture des flux d'entrée/sorties en cas de levée d'exception ? utilisation d'un finally ?

Les exceptions semblent être extrêmement utiles en plus d'être obligatoires par moment mais j'aimerais être sûr de bien les utiliser ??

Voici quelques exemples que j'ai fait sur lesquels vos avis me seraient utiles :

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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
public class AnalyseTrameGpsFile {
 
    public static void main(String[] args) {
 
            File ftrames = new File("trame1.txt");
            File fsortie = new File("latlong.txt");
            long taille = ftrames.length();
            long datemodif = ftrames.lastModified();
            Date d = new Date(datemodif);
            String date = d.toString();
            SimpleDateFormat formdate = new SimpleDateFormat("yyyy/MM/dd - HH:mm:ss");
            System.out.println(taille+"octets - "+formdate.format(d)+" - "+date);
 
            BufferedReader entree=null;
            FileWriter sortie = null;
            try
            {
                entree = new BufferedReader(new FileReader(ftrames));
                sortie = new FileWriter(fsortie, true);
                String ligne;
                try
                {
                    do
                    {
                        ligne = entree.readLine();
                            System.out.println(ligne);
                            String[] tabitemstrame = ligne.split(",");
                            sortie.append(date+" - LAT:"+tabitemstrame[1]+" - LONG:"+tabitemstrame[2]+"\r\n");
                     }while(ligne!=null);
                }
                catch(NullPointerException e)
                {
                    System.out.println("Erreur Pointeur Null !");
                }
                finally
                {
                    entree.close();
                    sortie.close();
                }
            }
            catch (FileNotFoundException ex) {
                String namefile = ftrames.getName();
                System.out.println("Le fichier : \""+namefile+"\" est introuvable. Arret du programme !");
            }
            catch (IOException ex) {
                String namefile = fsortie.getName();
                System.out.println("Le fichier : \""+namefile+"\" a subi une erreur. Arret du programme !");
 
            }
}

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
37
38
39
40
41
42
43
public class AnalyseTrameGpsFile {
 
    public static void main(String[] args) throws NullPointerException{
 
            File ftrames = new File("trame1.txt");
            File fsortie = new File("latlong.txt");
            long taille = ftrames.length();
            long datemodif = ftrames.lastModified();
            Date d = new Date(datemodif);
            String date = d.toString();
            SimpleDateFormat formdate = new SimpleDateFormat("yyyy/MM/dd - HH:mm:ss");
            System.out.println(taille+"octets - "+formdate.format(d)+" - "+date);
 
            BufferedReader entree=null;
            FileWriter sortie = null;
            try
            {
                entree = new BufferedReader(new FileReader(ftrames));
                sortie = new FileWriter(fsortie, true);
                String ligne;
                    do
                    {
                        ligne = entree.readLine();
                        if(ligne != null)
                        {
                            System.out.println(ligne);
                            String[] tabitemstrame = ligne.split(",");
                            sortie.append(date+" - LAT:"+tabitemstrame[1]+" - LONG:"+tabitemstrame[2]+"\r\n");
                        }
                     }while(ligne!=null);
                    entree.close();
                    sortie.close();
            }
            catch (FileNotFoundException ex) {
                String namefile = ftrames.getName();
                System.out.println("Le fichier : \""+namefile+"\" est introuvable. Arret du programme !");
            }
            catch (IOException ex) {
                //Comment savoir ici si l'exception est levée par FileWriter ou .close() ???????
                String namefile = fsortie.getName();
                System.out.println("Le fichier : \""+namefile+"\" a subi une erreur. Arret du programme !"); 
            }
    }

Merci d'avance pour votre aide.

[Heimdal]

Salut,

il n'y a pas vraiment de consensus sur la gestion des exceptions. L'idée de base est de traiter seulement les exceptions que ton programme peut tolérer, c'est à dire qui n'altère pas le fonctionnement attendu de ton programme.
Dans ton cas je dirai que tu ne devrais rien catcher et traiter les fermetures des flux dans un bloc finally.

[sleroux]

Bonjour ,

La run-time Java te garantit que le code dans un bloc finally sera exécuté. Exception ou pas.

A chaque fois que tu alloues une ressource, il est préférable de la libérer dans un bloc finally. Ainsi, tu es certain que les ressources allouées seront libérées dans tous les cas.

Concernant ton code, dans le bloc try "interne", je me limiterais au code suivant:

Code java :

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
 
                entree = new BufferedReader(new FileReader(ftrames));
                sortie = new FileWriter(fsortie, true);
                String ligne;
                try
                {
                    while((ligne = entree.readLine()) != null)
                    {
                            System.out.println(ligne);
                            String[] tabitemstrame = ligne.split(",");
                            sortie.append(date+" - LAT:"+tabitemstrame[1]+" - LONG:"+tabitemstrame[2]+"\r\n");
                     }
                }
                finally
                {
                    if (entree != null)
                         entree.close();
                    if (sortie != null)
                         sortie.close();
                }

Je ne vois pas l'intérêt pour toi d'intercepter NullPointerException. Il me semble plus simple (et plus efficace - et plus lisible) de remplacer ta boucle do { ... } while() par un while() { ... } Comme ci-dessus. A moins qu'il n'y ait un effet de bord qui m'échappe dans to code?

Remarque aussi les "if" dans le bloc finally. C'est pour prendre en compte le fait qu'une exception peut se produire dans les circonstances suivantes:
* lors de l'ouverture du fichier d'entrée (alors entree == null et sortie == null)
* lors de l'ouverture du fichier de sortie (alors entree != null et sortie == null)
* lors du traitement (alors entree != null et sortie != null)

Sans les "if"s les deux premiers cas vont générer une NullPointerException au moment d'appeler la méthode close() sur une variable non initialisée.

Espérant t'avoir aidé,
- Sylvain

[psykoprof]

Merci beaucoup pour vos réponses. Je comprends mieux l'utilisation des exceptions.

Donc l'imbrication de 2 blocs try n'est pas mauvaise et semblerait même convenir !? ne pourrait-on pas faire cela avec un seul ?

[adiGuba]

Salut,

Je ne vois pas l'intérêt pour toi d'intercepter NullPointerException. Il me semble plus simple (et plus efficace - et plus lisible) de remplacer ta boucle do { ... } while() par un while() { ... } Comme ci-dessus.

+1

Remarque aussi les "if" dans le bloc finally.

Là je serais plus nuancé...
Les bloc finally devrait comporter le moins de code possible, afin d'éviter tout risque de problème.
Ici c'est les exceptions sur les méthodes close() qui pourrait poser soucis, et empêcher la fermeture du second flux.

Perso je conseillerai d'utiliser un try/finally par ressource :

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
 
	BufferedReader entree = new BufferedReader(new FileReader(ftrames));
	try {
		FileWriter sortie = new FileWriter(fsortie, true);
		try {
			String ligne;
			while((ligne = entree.readLine()) != null) {
				System.out.println(ligne);
				String[] tabitemstrame = ligne.split(",");
				sortie.append(date+" - LAT:"+tabitemstrame[1]+" - LONG:"+tabitemstrame[2]+"\r\n");
			}
		}
		finally {
                         sortie.close();
                }
	} finally {
		entree.close();
	}

a++

[sleroux]

Tu as parfaitement raison adiGuba: il n'y a qu'avec des try{} finally{} imbriqués qu'on peut prendre en compte les exceptions potentielles générées par close()!


Par contre, je me pose une question sur l'expression suivante:

Code java :

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

1
2
 
	BufferedReader entree = new BufferedReader(new FileReader(ftrames));

N'y aurait-il pas un risque de voir la construction du nouveau FileReader réussir, mais la construction du BufferedReader échouer en générant une exception? Dans ce cas, le fichier ne serait pas fermé...

A+
- Sylvain

[tchize_]

N'y aurait-il pas un risque de voir la construction du nouveau FileReader réussir, mais la construction du BufferedReader échouer en générant une exception? Dans ce cas, le fichier ne serait pas fermé...

A+
- Sylvain

Sur le principe, oui, en pratique non. Il n'y a pas de code dans le constructeur BufferedReader suceptible de foirer:

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
    public BufferedReader(Reader in, int sz) {
	super(in);
	if (sz <= 0)
	    throw new IllegalArgumentException("Buffer size <= 0");
	this.in = in;
	cb = new char[sz];
	nextChar = nChars = 0;
    }
 
    /**
     * Creates a buffering character-input stream that uses a default-sized
     * input buffer.
     *
     * @param  in   A Reader
     */
    public BufferedReader(Reader in) {
	this(in, defaultCharBufferSize);
    }
    protected Reader(Object lock) {
	if (lock == null) {
	    throw new NullPointerException();
	}
	this.lock = lock;
    }

[unknow0]

Par contre, je me pose une question sur l'expression suivante:

Code java :

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

1
2
 
	BufferedReader entree = new BufferedReader(new FileReader(ftrames));

N'y aurait-il pas un risque de voir la construction du nouveau FileReader réussir, mais la construction du BufferedReader échouer en générant une exception? Dans ce cas, le fichier ne serait pas fermé...

a ceci pres que le constructeur de BufferedReader ne remonte pas d'exception.
donc c'est un cas qui ne peu arriver

[sleroux]

Merci unknow0 et tchize_ pour vos éclaircissements.

J'étais un peut dans l'optique de me dire qu'il pouvait y avoir une erreur OutOfMemoryError lors de la création du BufferedReader.

Mon idée était de me dire qu'on pourrait retrouver un code similaire au snippet présenté dans une application comme un serveur: Dans ce cas l'application pourrait être susceptible de gérer proprement les erreurs d'exécutions lors du traitement d'une tache lourde. Mais à condition que localement le code invoqué prenne la peine de libérer les ressources allouées quoi qu'il arrive.


Maintenant, tout cela reste très hypothétique. Et peut-être juste faux: y'a-t-il sérieusement un moyen de récupérer proprement après une erreur aussi critique que OutOfMemory? En googlant un peu, j'en doute...


A+
- Sylvain

[psykoprof]

Vous lire est très instructif même si vers la fin j'ai un peu décroché. Je ne maitrise pas encore Java pour tenir une discussion aussi poussée mais n'hésitez pas à compléter ce sujet concernant l'utilisation du try/catch/finally.

adiGuba : Dans ton exemple, il n'apparait pas les catch ? J'imagine que je dois tout de même les placer au niveau du

Code :

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

BufferedReader entree = new BufferedReader(new FileReader(ftrames));

avec à nouveau un try/catch qui englobe tout le reste ?

Si c'est le cas ça devient rapidement l'usine pour une appli relativement simple !? ou alors il y encore un truc qui m'échappe

[tchize_]

Merci unknow0 et tchize_ pour vos éclaircissements.

J'étais un peut dans l'optique de me dire qu'il pouvait y avoir une erreur OutOfMemoryError lors de la création du BufferedReader.
...
y'a-t-il sérieusement un moyen de récupérer proprement après une erreur aussi critique que OutOfMemory? En googlant un peu, j'en doute...

C'est une erreur grave qui peux avoir mis en l'air tout et n'importe quoi. Le seul cas de récupération que je vois est celui ou tu réserve un gros array de quelques centaines de Megs en mémoire et que ca déclenche l'erreur. Mais là tu traite directement autour de l'allocation . Sinon, c'est une "petite" réservation qui a foiré, t'es limité coté jvm tu va foirer et refoirer encore (traduction, une outofmemoryerror n'arrive jamais seule )

adiGuba : Dans ton exemple, il n'apparait pas les catch ?

Il n'est pas nécessaire. On ne catch pas d'exception ici, on ajoute juste un bloc finally (une garantie de nettoyage). L'appelant se chargera de gérer l'exception)

Quand au filereader, il peux déclencher une exception à la création, qui devra être traitée, mais il n'a pas besoin de finally, car si exception dans le constructeur -> rien à nettoyer.

[adiGuba]

Oui le try/catch engloberait le tout, comme cela :

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
try {
	BufferedReader entree = new BufferedReader(new FileReader(ftrames));
	try {
		FileWriter sortie = new FileWriter(fsortie, true);
		try {
			String ligne;
			while((ligne = entree.readLine()) != null) {
				System.out.println(ligne);
				String[] tabitemstrame = ligne.split(",");
				sortie.append(date+" - LAT:"+tabitemstrame[1]+" - LONG:"+tabitemstrame[2]+"\r\n");
			}
		}
		finally {
			sortie.close();
		}
	} finally {
		entree.close();
	}
} catch (IOException e) {
	System.err.println("Erreur de traitement : " + e);
	e.printStackTrace();
}

Il y a plusieurs intérêt à cela :

• Chaque ressource possède son propre bloc finally.
• Un traitement unique des erreurs.
• Un traitement des erreurs biens séparé du reste du code, ce qui fait qu'il suffit de "supprimer" le try/catch si on veut simplement faire remonter l'exception.

C'est vrai que ca peut paraitre très verbeux, mais il y a surtout beaucoup d'indentation. On pourrait vouloir utiliser un seul try/catch/finally, mais dans ce cas là c'est encore plus verbeux si on veut faire cela correctement, en particulier à cause des exceptions sur la libération des flux qui implique plusieurs imbrications sur les fermetures.

En fait lorsqu'on regarde le code précédent avec un try/catch/finally, on trouve une grosse erreur dans le finally :

Code :

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

1
2
3
4
5
6
finally {
	if (entree != null)
		entree.close();
	if (sortie != null)
		sortie.close();
}

En effet en cas d'exception sur le premier close(), le bloc finally sera logiquement interrompu et le second fichier restera ouvert

Il est impératif d'y rajouter de nouveaux try/finally et un try/catch (si on veut gérer les exceptions) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
finally {
	try {
		try {
			if (entree!=null)
				entree.close();
		} finally {
			if (sortie!=null)
				sortie.close();
		}
	} catch (IOException e) {
		System.err.println("Erreur de traitement : " + e);
		e.printStackTrace();
	}
}

Bref c'est plus complexe et source d'erreur, donc de problème potentiel.
Tu y gagnes en indentations, mais tu perds en code, et en particulier dans une section assez critique (le finally et la fermeture des fichiers). Le problème c'est qu'en cas d'ajout d'une nouvelle ressource tu devras toucher un peu à tout, et que cela augmente le risque d'erreur.

Alors que la solution du try/finally par ressource est plus simple à mettre en place car elle se base sur un pattern tout con en 3 étapes :

Code :

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

1
2
3
4
5
6
// 1 . Déclaration de la ressource
try {
	// 2 . Utilisation de la ressource
} finally {
	// 3 . Fermeture de la ressource
}

La solution du try/finally est la plus simple à mettre en place, et celle où il y a le moins de risque d'erreur...


Enfin en réalité le try/finally peut engendrer des soucis dans le cas où le bloc finally génère une exception alors que le bloc try a lui même engendrer une exception. Mais c'est un cas assez rare et qui n'est pas mieux gérer par le try/catch/finally...



Enfin il est à noter que Java 7 devrait simplifier cela via une nouvelle syntaxe...


a++

[tchize_]

Enfin il est à noter que Java 7 devrait simplifier cela via une nouvelle syntaxe...


a++

Quand il sortira

[adiGuba]

tut tut tut ! On ne se moque pas ...


Enfin on se consolera en pensant que le report sera utile à quelque chose (expression lambda, multicatch, defenders methods)


a++

[tchize_]

Enfin on se consolera en pensant que le report sera utile à quelque chose (expression lambda, multicatch, defenders methods)

acquisition, remplacement des chefs

[psykoprof]

Merci beaucoup adiGuba pour tes explications. Merci aux autres également pour leur aide. Je comprend mieux la philosophie Java et commence à en voir les avantages et inconvénients.

J'avoue avoir une petite préférence pour Qt concernant le développement d'appli graphique classique et gestion réseau mais bon je ne suis pas suffisamment expérimenté pour tenir un débat là-dessus et loin de moi l'idée de vouloir alimenter un troll. C'était juste pour dire que je trouvais Java plus difficile à appréhender mais bon j'ai pas le choix vis à vis du boulot donc je fais avec.

Merci encore, à plus ! et vivement Java 7 pour voir les nouveautés.