Discussion :

[zoaax]

Bonsoir,

vous allez encore dire "encore une question sur la bonne utilisation des exceptions". Ce n'est pas vraiment ça.
Nous sommes partagés au sein de notre équipe sur la bonne utilisation des exceptions. J'aimerais avoir votre avis sur la question. Je considère pour ma part qu'une exception ne doit être lancé que lorsqu'une situation anormale se produit au sein de l'application: "Echec de connexion à la base de données", "Echec d'ouverture d'un fichier" ou "Arguments passés à une méthode publique non corrects".

Je développe actuellement une application qui doit notamment valider l'épaisseur d'une feuille de papier enroulée en bobine. J'ai développé une méthode métier qui contrôle si l'épaisseur est dans la tolérance avant de la sauvegarder en base de données. L'un de mes collègues considère que ma méthode devrait retourner une exception métier "EpaisseurIncorrectException" alors que moi je pense que ma méthode devrait retourner un booleen: FALSE->Epaisseur incorrect, TRUE->Epaisseur correct.

Autre exemple concret, une méthode d'authentification d'un utilisateur.
Ce même collègue considère que cette méthode devrait lancer une exception "InvalidPasswordException" si le mot de passe est incorrect et une exception "InvalidUserException" si l'utilisateur n'existe pas.
Moi je pense que la méthode devrait retourner un booleen: FALSE->Echec d'authentification, TRUE->Utilisateur authentifié.
Il argumente en disant à juste titre: "Comment fais-tu avec ton booleen pour distinguer si l'utilisateur ou le mot de passe sont invalides ?"

Et vous qu'en pensez-vous ?

Merci de me faire profiter de votre expérience.
++

[StormimOn]

En général il faut éviter de lever des exceptions si ce n'est pas nécessaire, les cas que tu cites en font partis comme tu l'as compris.

Une exception c'est pour les situations anormales que l'on ne peut pas gérer de manière simple :
- connexion à un serveur (pas de réseau, lenteur réseau et donc timeout, ...)
- suppression d'un fichier (le fichier peut être pris par un processus, l'utilisateur n'a pas les droits, ...)
- ...

Pour ce qui est du contrôle des données, un retour booléen vrai/faux qui indique si la donnée est correcte suffit largement. Eventuellement on peut imaginer renvoyer un booléen ainsi qu'une chaîne pour indiquer le problème le cas échéant (et l'afficher à l'utilisateur). Mais surtout pas d'exception, le contrôle de données saisies par l'utilisateur n'est pas quelque chose d'anormal.

Pour la connexion de l'utilisateur pareil, la saisie d'un mot de passe invalide n'a rien d'une situation anormale, c'est même tout le contraire dans ce contexte. Il faut juste un objet dédié à la gestion de la connexion qui permettra d'avoir les informations nécessaires si besoin.

On pourrait imaginer par exemple

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
LoginManager login = new LoginManager();
if (!login.Login("toto", "motdepasse"))
{
    switch(login.FailReason)
    {
        case FailReason.BadLogin:
            // Traitement si échec car login inexistant.
            break;
        case FailReason.BadPassword:
            // Traitement si échec car mot de passe incorrect.
            break;
        default:
                throw new ArgumentException("On ne doit pas passer là. Exception pour le debug");
    }
};

C'est un exemple comme un autre. Pour l'exception c'est quelque chose que je fais en général sur un switch avec une énumération, lorsque je sais que l'énumération peut être amené à évoluer (et même lorsque ce n'est pas le cas, par habitude). Comme ça si j'oublie de modifier je me ferais rappeler à l'ordre pendant le développement ou les tests

Au final tout le problème c'est de déterminer ce qu'est une situation normale/anormale, afin de savoir s'il faut ou non utiliser une exception. Et là, tout dépend du contexte.

[Flamby38]

Je pense que les 2 approches se valent, le tout c'est d'etre homogène sur le programme pour ne pas avoir parfois des exceptions, parfois des valeurs de retour.

Perso je pencherais plutot pour ton approche, en revanche il est vrai qu'un booléen c'est peu parlant. Je recommande plutot de retourner un objet qui peut comporter un entier (0=OK, puis a toi de mettre des numeros pour les differentes erreurs attendues) et une chaine de caractere qui décrit le probleme ("Utilisateur inconnu" par exemple), puis il se peut qu'il évolue en fonction des besoins. Cet objet peut-être programmé une fois et réutilisé à chaque fois qu'une fonction peut contenir des erreurs.

[MetalGeek]

Salut,

je pense pour ma part que les deux approches ne se valent pas du tout.

Les "exceptions" portent bien leur nom : elles sont faites pour signaler que le programme exécute une opération qui ne doit pas être possible en fonctionnement normal. Par exemple, tester si l'épaisseur de papier est correcte, et signifier qu'elle ne l'est pas, fait partie du fonctionnement normal de l'application, et je pense à 100% de certitude qu'il ne faut pas lever d'exception à cet endroit.
Pour ton second exemple, pas besoin d'exception non plus.
Pour ce qui est de

"Comment fais-tu avec ton booleen pour distinguer si l'utilisateur ou le mot de passe sont invalides ?"

il n'y a pas que les booléens dans la vie, heureusement ! Tu créés soit une enum du genre

Code :

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

1
2
3
4
5
6
7
8
 
public enum AuthenticationState
{
    UnknownError,
    InvalidUsername,
    InvalidPassword,
    Succeeded
}

si tu veux aller vite, sinon en mieux tu créés un type encapsulant un booléen pour "OK" ou "rejeté" + une enum spécifiant la raison de l'echec (c'st d'ailleurs le modèle choisi par Microsoft dans le système d'appartenance Membership dans ASP).

Voilà, bon code...

[zoaax]

Super, vous me donnez raison.
Merci pour vos réponses.
Est-ce que d'autres ont un avis sur la question ?

++

[Kalagan64]

Je trouve que gérer les erreurs avec des exception est plus pratique.
Par exemple lors de la création d'un nouvel utilisateur :
- dans la méthode de la page lié au clic sur le bouton, on catche les exceptions de type "ExceptionMetier" (dont vont hérité des exceptions du genre "MotDePasseTropCourtExcetpion" ou "LoginDejaPrisException").
Dans ce cach on fait directement

Code :

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

1
2
3
4
catch(ExceptionMetier em)
{
	afficherDansUnePopup(em.message);
}

De plus, la valeur de retour est souvent utile pour autre chose que l'erreur.
Par exemple pour connaitre l'Id de l'utilisateur qui a été créé (utile pour les TU)