Discussion :

[dev.go]

Disons que j'ai une structure de données comme la suivante en attibut de ma classe qui pour l'exemple a les données suivantes


data ={{100,100,100},{88.5,90.6,99.6},{80.4,85.6,88.6}};

qui représente les données suivante le taux bas dans 2 ans est de 80.4 , le taux MEDIAN dans 1 an est de 90.6 et le taux Maximum dans 0 ans est de 100.

J'ai donc la méthode suivante

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
 
 
	public double getTaux(int annee, String type) {
 
		double result =Double.NaN;
		if (type.equals(Maclasse.TAUX_MINIMUM)) {
			result = data[annee][1];
		}
		if (type.equals(Maclasse.TAUX_MEDIAN)) {
			result = data[annee][2];
		}
		if (type.equals(Maclasse.TAUX_MAXIMUM)) {
			result = data[annee][3];
		}
 
		return result ;
	}

Mais voila, je ne sais pas ou et quand géré les possibles erreurs ?
Que faire si type n'est pas égale a une des 3 chaines caracteres souhaités lancé une exception ? retourner NaN et que faire si année est supérieur au nombre d'année que je connais présent dans la structure de données lancé une exception ? retourner NaN ? Bref je nage un peu et un peu d'aide dans le design serait le bien venue
En vous remerciant

[esired]

Bonsoir.
Une solution serait d'utiliser des tables de hachage.
Une pour chaque type de taux. Tu auras donc trois tables de hachage.
Les clés des tables seront les années et les valeurs les taux.
Illustration.

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
 
private HashMap<Integer, Double> tauxMedian, tauxMin, tauxMax;
...
// remplir les tables comme il se doit.
...
public Double getTaux(int annee, String type) {
                Double result = null;
 
		if (type.equals(Maclasse.TAUX_MINIMUM)) {
			result = tauxMin.get(annee);
		}
		if (type.equals(Maclasse.TAUX_MEDIAN)) {
			result = tauxMedian.get(annee);
		}
		if (type.equals(Maclasse.TAUX_MAXIMUM)) {
			result = tauxMax.get(annee);
		}
 
		return result ;
}

Ainsi, à chaque appel, si la valeur renvoyée est égale à null, tu sauras que l'année ou le taux est invalide. Plus besoin d'exception.

PS
On peut encore faire mieux en utilisant une seule table de hachage:
private HashMap<String, HashMap<Integer, Double>> taux;
Mais il y a le risque d'un NullPointerException.

[dev.go]

Merci de ta réponse,

Mais ma question était plus la suivante.

Si ma méthode ne peut pas renvoyer de valeur car les arguments de la méthode ne sont pas bon.

Est ce que je dois lancer un exception ?
Est ce que je dois retourner null ?
Est ce que je dois retourner NaN ?

Est ce qu'il y a une "best practices" ou des critères de décisions pour choisir entre ces options.

[Kazh Du]

Si tu ne peux pas renvoyer de valeur, tu te trouves clairement dans un cas anormal et il faut pouvoir le signaler à l'utilisateur. Renvoyer null laisse un doute (Est-ce que ta classe à été mal initialisée ? Est-ce que ta fonction a été mal utilisée ? etc...) De plus, les valeurs null ont tendance à amener d'autres problèmes qu'il faudra écarter de toute manière.

Les exceptions ont été crées justement pour ça et c'est une des forces du java, il serait dommage de ne pas les utiliser. Un autre avantage est que tu peux choisir à quel moment les traiter (sur l'IHM en affichant une boite de dialogue avec le contenu du message par exemple)

Je te recommande d'ailleurs de créer ta propre classe d'exception ce qui permettra à l'utilisateur de ta classe de faire le tri sur les différents problèmes rencontrés.

[fastdeath124]

Si tu ne peux pas renvoyer de valeur, tu te trouves clairement dans un cas anormal et il faut pouvoir le signaler à l'utilisateur. Renvoyer null laisse un doute (Est-ce que ta classe à été mal initialisée ? Est-ce que ta fonction a été mal utilisée ? etc...) De plus, les valeurs null ont tendance à amener d'autres problèmes qu'il faudra écarter de toute manière.

Les exceptions ont été crées justement pour ça et c'est une des forces du java, il serait dommage de ne pas les utiliser. Un autre avantage est que tu peux choisir à quel moment les traiter (sur l'IHM en affichant une boite de dialogue avec le contenu du message par exemple)

Je te recommande d'ailleurs de créer ta propre classe d'exception ce qui permettra à l'utilisateur de ta classe de faire le tri sur les différents problèmes rencontrés.

Je confirme, je pense qu'ici la meilleure solution est d'employer des exceptions (c'est stable est efficace).
Voici un lien qui peut être très utile.
J'ai une autre remarque qui ne concerne pas la question : Il préférable d'éviter l'utilisation des instructions "if" consécutifs qui ne peuvent pas être exécutés à la fois. Par exemple ici, "type" ne peut pas être égal à "Maclasse.TAUX_MINIMUM" et "Maclasse.TAUX_MEDIAN", il faut donc utiliser "if/else" ou "switch/case" (algorithmiquement c'est beaucoup mieux).

[tchize_]

Si il s'agit d'une utilisation erronée de la méthode -> Exception (cas typique: IllegalArgumentException)
Si il s'agit d'une impossibilité mathématique de faire le calcul (cas typique, la division par 0) alors les deux peuvent se justifier:
Exception si tu ne veux pas que l'erreur se propage dans le calcul
NaN si, au contraire, tu veux terminer ton calcul global et que ça a un sens mathématique de na pas pouvoir calculer un membre.

Là, ça dépendra de l'utilisation de ta librairie.