Discussion :

[Deewens]

Bonjour,

Je développe actuellement une application pour l'IUT, c'est un devoir à rendre vendredi. Et je me posais une question. Mon code fonctionne, mais je cherche à l'optimiser au maximum, principalement sur la gestion des erreurs.
Donc, je dois coder un programme permettant de gérer des données stockés dans une BDD MySQL et aussi dans une List Java. Pour ça, on utilise le design pattern DAO de niveau 2.

J'ai lu ce sujet qui parle d'anti pattern : https://www.developpez.net/forums/d8...eption-metier/
Et je ne comprend pas bien la différence entre une bonne utilisation ou non des exceptions.

Voici une partie de mon 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
 
@Override
	public boolean create(Abonnement obj) throws Exception {
		Iterator<Abonnement> dataIterator = data.iterator();
 
		while (dataIterator.hasNext()) {
			Abonnement datum = dataIterator.next();
			if(obj.getId_client() == datum.getId_client() && obj.getId_revue() == datum.getId_revue()) {
				throw new IllegalArgumentException("Le client n°" + obj.getId_client() + " que vous avez choisi est déjà abonné à cette revue.");	
			}
		}
 
		boolean ok = this.data.add(obj);
 
		return ok;
	}

Ma classe métier "Abonnement" a une clé primaire composite, composé de {id_client, id_revue}, ce qui complique pas mal la création des classes DAO ! Et pour ça, je dois donc vérifier si la clé primaire n'existe pas déjà dans la list.
Donc, je boucle sur "data" qui est la liste contenant les données et si la clé primaire existe déjà, j'utilise un throw new qui me renvoie l'erreur, erreur que je récupère dans un try - catch dans ma classe Main et qui m'affiche ça :

Code :

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

[ListeMemoire] Erreur ajout "Abonnement" : Le client n°1 que vous avez choisi est déjà abonné à cette revue.

Donc, je voudrais savoir si c'est une bonne façon d'utiliser les Exception, et si non, comment je pourrais mieux gérer ce genre de chose?

Merci !

[OButterlin]

Ben là, on est plutôt dans la mauvaise utilisation... d'autant que ta méthode renvoie un boolean pour dire que ça c'est bien passé ou non.
Tu devrais plutôt faire un return false plutôt que ton throw new Exception(...)

[Deewens]

D'accord, ouais, j'avais raison d'hésiter...

Du coup, j'ai un peu de mal à comprendre dans quel situation le throw new doit être utilisé. J'ai vu pas mal de bout de code sur des tutoriels utiliser le throw new pour tester les valeurs d'un constructeur par exemple. Genre, une classe Ville, qui ne peut pas avoir un nombre négatif d'habitants, et donc ils utilisent un throw new pour renvoyer l'erreur.

[yildiz-online]

Pour ma part, j'aurais considéré ça comme une bonne utilisation, une exception va casser le flux d'éxécution, le traitement de création se faisant certainement dans un flux plus complexe(création puis affichage du résultat à l'utilisateur et potentiellement d'autres choses entre les 2), il est plus simple de juste tout arréter jusqu'à l'interception de l'exception.

Un autre point, est que ce cas n'est pas le seul cas qui pourrait empécher le traitement, une autre erreur métier, par exemple que l'abonnement n'est plus dispo.
Egalement, une erreur technique dans la DB lancera une exception, en utilisants différentes exceptions, ou du moins avec des messages différents, on peut notifier l'utilisateur de manière unifiée en gardant uniquement 2 flux: 1 "ça se passe bien", et l'autre "ça ne marche pas, voir le message ou le type d'exception pour savoir pourquoi".

Je ne suis pas fan des return boolean parce qu'a tous les coups, si on ne connait pas l'api, on oublie de les vérifier, et donc on ne traite pas les erreurs(la classe java.io.File est un bon exemple).

[OButterlin]

Pour ma part, j'aurais considéré ça comme une bonne utilisation, une exception va casser le flux d'éxécution, le traitement de création se faisant certainement dans un flux plus complexe(création puis affichage du résultat à l'utilisateur et potentiellement d'autres choses entre les 2), il est plus simple de juste tout arréter jusqu'à l'interception de l'exception.

Un autre point, est que ce cas n'est pas le seul cas qui pourrait empécher le traitement, une autre erreur métier, par exemple que l'abonnement n'est plus dispo.
Egalement, une erreur technique dans la DB lancera une exception, en utilisants différentes exceptions, ou du moins avec des messages différents, on peut notifier l'utilisateur de manière unifiée en gardant uniquement 2 flux: 1 "ça se passe bien", et l'autre "ça ne marche pas, voir le message ou le type d'exception pour savoir pourquoi".

Je ne suis pas fan des return boolean parce qu'a tous les coups, si on ne connait pas l'api, on oublie de les vérifier, et donc on ne traite pas les erreurs(la classe java.io.File est un bon exemple).

Tout dépend de ce qu'il y a avant ou plutôt de ce qu'on veut faire.
Contre exemple :
L'utilisateur saisie des données et les enregistre dans une liste.
Ensuite, on traite cette liste pour ajouter en DB
Si la saisie existe déjà, on s'en fou... sinon, on ajoute
Là, l'exception casse la boucle de traitement alors que le test du boolean permet de s'en sortir sans l'artillerie lourde.

Code :

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

1
2
3
4
5
6
7
8
 
List<DonneesSaisies> aEnregister = ...
int count = 0;
for (DonneesSaisies donneesSaisie : aEnregistrer)
{
   if (ajouter(donneesSaisie)) ++count;
}
System.out.println("On a enregistré " + count + " donnée" + (count > 1 ? "s":""));

Dans le cas d'une exception, il faudrait faire

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
...
for (DonneesSaisies donneesSaisie : aEnregistrer)
{
   try
   {
      ajouter(donneesSaisie); 
      ++count;
   }
   catch (Exception e)
   {
      ...
   }
}
...

Bref, il faut trancher au cas par cas... mais la règle générale qu'on peut y voir est : "Si on peut éviter une exception, alors il faut l'éviter"

[Deewens]

Bon, je comprend mieux.

Je vous remercie de vos réponses.. J'ai vraiment beaucoup de mal à juger, si mon code doit faire tel chose ou tel autre chose. Mais je suppose que ça arrivera avec l'expèrience ^^ !