Discussion :

[cryo94]

Bonjour et bon,ne année a tous !

Je suis entrain de développer la couche métier de mon application et j'aimerai profiter de vos expérences pour savoir vos bonnes pratiques en matière de gestion des retours indésirables des méthodes de services.

Voici mon code très simple

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
    @Autowired
    RightRepository rightRepository;
    @Autowired
    RoleRepository roleRepository;
 
 
    @Override
    public Role createRole(Role role) {
        if(!checkRoleNameAlreadyExist(role.getName())){
            return roleRepository.save(role);
        }else{
 
        }
    }
 
    @Override
    public boolean checkRoleNameAlreadyExist(String name) {
        return (roleRepository.findByName(name) != null );
    }

Je stock en base de données un objet rôle ou le nom est unique.
Dans ma couche de service je fais donc un check pour savoir si un rôle avec ce nom existe déjà.
Si il n'existe pas je le crée sinon ... on arrive au sujet du post

D'habitude je gère avec des exceptions mais je ne trouve pas cette méthode propre.
Je veux récupérer le rôle nouvellement crée donc je dois renvoyer un objet rôle et par conséquent je ne peux pas renvoyer un string du style "ok" ou "existe déjà"

Je m'en remets à vous

[tchize_]

Qu'est-ce qui ne te plaît pas dans le fait de lancer une exception? Cette méthode est supposée créer un nouveau Role, si elle n'y arrive pas, il n'y a que deux possibilité: renvoyer null, qui ne founris aucune information utile et nécessite de faire des check spécifiques par la suite du coté de l'appelant, ou lancer une exception checkée, ce qui force l'appelant à en tenir compte.

[cryo94]

En fait c'est qu'avec cette méthode, si l'on souhaite être rigoureux, il faut une exception par type d'erreur.

Par exemple si j'ai une classe Membre et que l'email, le pseudo et son numéro de carte d'identité sont uniques.
Alors il faut une exception pour chacun des champs uniques car le traitement de l'unicité ne fera peux être pas apparaître le même résultat à l'utilisateur en fonction de son pseudo ou de son email.

Tu va me dire que c'est pas le nombre de classe qui importe mais ca va faire beaucoup de code pour traiter le cas.

D’où ma question sur le fait si il existe d'autres moyens

[thelvin]

Une Exception c'est aussi une classe normale.

Tu as qu'à mettre dedans tout ce dont tu as besoin pour décrire l'erreur, pas besoin d'en créer une nouvelle pour chaque possibilité. Et il est aussi possible de créer une hiérarchie d'Exceptions, pour celles qui ne se décriraient pas pareil.

Par exemple, PneuCreuvéException et MoteurExploséException sont des sous-classes de VoitureException et peuvent être traitées par un catch(VoitureException e)