Discussion :

[laclac]

Bonjour,

Les exceptions sont pour beaucoup d'étudiants comme moi un problème.
Difficiles à gérer, secondaires pour les néophytes,... elles sont souvent bâclées et très très généralistes : une balise try catch et c'est fini...

Alors je me suis renseigné pour améliorer mon approche.
Et on m'a dit une chose qui m'a surpris, c'est que une fonction doit avoir un seul but, celui pour lequel elle a été conçue. Et qu'il ne faut faire aucun contrôle dans celle-ci mais, en cas d'erreur, on lève l'exception..

Pour être plus concret voici un exemple :
Je fais un code qui demande la date de naissance de l'utilisateur et la traite.
Je crée alors un test de contrôle de la saisie et le traitement :

Code :

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

1
2
3
Saisie = '12/05/zer'
if controle(saisie) = true then
Traitement (saisie) else MsgBox(Saisie incorrect);

On m'a fait part de que ce code n'était pas correct car la procédure n'a pour but que d'obtenir la saisie et non de la contrôler. Le contrôle ne se fait que si la saisie est erronée, le traitement va bugger et donc exception... Et il faut donc gérer l'exception. Voici le code dit correct dans l'esprit :

Code :

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

1
2
3
4
5
6
Saisie = '12/05/zer'
try
Traitement(saisie)
 catch(..){
MsgBox(Saisie incorrect);
}

Cela est une autres approche que la mienne que je vais sans doute adopter mais j'aimerais connaître votre avis ?

[hassanibi]

moi je trouve qu'il vaut mieux traiter l'exception par un test si on connais la source de cette exception,

[DrTopos]

Si tu veux connaître un langage dans lequel il n'y a pas de notion d'exception (eh oui, c'est possible, ce qui prouve bien que cette notion n'est pas indispensable), va voir ici.

[trattos]

Et si la solution c'était de créer une fonction qui va justement vérifier la saisie et interrompre l'ensemble du programme en cas d'erreur?
Moi c'est ce que je fais comme ça chaque fonction garde son but initial!

[bountykiller]

Ce qui est bien avec les exeptions, c'est que si tu ne traite pas le problème dans la méthode appelante, tu peux toujours le faire dans la méthode appelante de la méthode appelante (ben vi, c'est le principe à savoir que les exeptions remontent dans la liste des méthodes appelantes tant qu'elle ne sont pas gérée).

Maintenant, dans le cas précis que tu cite, cela ne change pas grand chose vu que ton exeption est directement gérée. Mais ça pourrait l'être si ailleurs dans le code tu avais une autre fonction qui appelle controle(saisie) et qui pour une raison xyz ne peut pas traiter elle même l'execption (je n'est pas d'exemple précis en tête). Et finallement c'est peut-être mieux car quelqu'un d'autre peut toujours utiliser ta fonction sans vérifier ce qu'elle retourne. Au moins avec les exeptions, son code n'ira pas plus loin, alors qu'avec un code d'erreur, bah l'exécution continue et on ne sait pas ce qui se passe. (Si j'entre '12/05/aaaaaaa_puis_un_gros_mechant_virus_pas_beau_du_tout' par ex ;-) )

Bon, ben finallement je crois que je me suis convaincu moi-même de l'intéret des exeptions tiens

[vincent63]

En fait, (si je ne me trompe pas) on gère les exceptions de la manière suivante :

Supposons que tu aies une méthode qui lise une date au format dd/mm/yyyy dans un fichier.
Une fois, la chaine de caractères lue, tu testes sa validité :

Si elle est bonne, tu la renvoies, sinon, tu signales à la méthode appellante qu'il y a eu un problème.
C'est ici que tu lèves l'exception. Cette façon de faire te permet de choisir le type de problème lié à la non validité de la date.

Par exemple, tu peux lever une exception de type DateTropLongueException ou DateInvalideException (dans le cas du 30/02/XXXX par exemple) etc.

L'intéret pour la méthode appelée est de renvoyer soit la valeur correcte, soit une indication expliquant pourquoi il y a eu une erreur. Il ne faut surtout pas renvoyer une valeur bidon genre null ou autre, car la méthode appelante n'aura aucun moyen de savoir pourquoi on a cette valeur et comment la gérer.

La méthode appelante elle, doit gérer les différents types d'exceptions succeptibles d'être levées. C'est là qu'intervient le bloc try catch.

Dans le cas d'une DateTropLongue par exemple, le programme indiquera à l'utilisateur que le fichier lu est corrompu. Dans le second cas, il indiquera que la date n'est pas valide, ou alors il initialisera avec la première date valide avant celle lue. etc.

Voilà un exemple de code fait à l'arrache qui devrait te permettre de mieux comprendre.

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
		public Date lireDate()
		throws  DateTropLongueException, 
				DateTropVieilleException,
				DateFuturException {
			String string = maFonctionLireDate();
			if (string.length()>10)
				return new DateTropLongueException();
			Date date = new Date();
			SimpleDateFormat simpleDateFormat = new SimpleDateFormat("dd/MM/yyyy");
			date = simpleDateFormat.parse(string);
			Date debut = simpleDateFormat.parse("01/01/1950");
			Date fin = simpleDateFormat.parse("01/01/2050");
			if (date.before(debut))
				return new DateTropVieilleException();
			if (date.after(fin))
				return new DateFuturException();
			return date;
		}
		
		
		public void utiliserDate(){
			Date date;
			try{
				date = lireDate();
			}catch(DateTropLongueException e){
				System.err.println("Fichier corrompu");
				return;
			}catch(DateTropVieilleException e){
				date = new SimpleDateFormat("dd/MM/yyyy").parse("01/01/1950");
			}catch(DateFuturException e){
				date = new SimpleDateFormat("dd/MM/yyyy").parse("01/01/2050");
			}
				traiterDate(date);
		}

Dans le premier cas, la date récupérée n'est pas gérable. Dans les suivants, elle est correcte mais "hors bornes" et il y a moyen (enfin c'est lié au fonctionnel) de trouver des dates valides, et donc de revenir à une situation d'execution sans erreur.