juillet
2009
Salut
En regardant les exemples venus avec les plugins Netbeans pour Wicket, j’ai découvert une originale de gérer les erreurs, via des enums, devenant ainsi une belle extension des codes retour à l’ancienne.
Pour ma part, je fonctionnais beaucoup avec des Exceptions jusqu’ici, mais c’est assez lourd.
Voyons plus en détail ce que j’ai vu :
– l’auteur a une énumération avec les différents codes d’erreur, cela donne:
PASSWORD_EMPTY_OR_NULL, USER_EXISTS, BAD_PASSWORD, INCORRECT_PASSWORD,
UNKNOWN_USER, NON_MATCHING_PASSWORD, EXCEPTION, EMPTY_EMAIL, BAD_EMAIL;
...
– l’auteur a également le toString de son enum, en faisant ainsi :
public String toString() {
switch (this) {
case BAD_PASSWORD :
return "Bad password";
case USER_EXISTS :
return "User already exists";
case PASSWORD_EMPTY_OR_NULL :
...
– enfin, dans son code, il procède ainsi :
if (signInResult == null) {
...
Pour ma part, jusqu’ici, j’avais tendance à beaucoup gérer mes erreurs au moyen d’exceptions… Que dites vous de cette approche ? Comment procédez vous vous même ?
Curieux de voir ça !
++
ZedroS
Cela peut être pratique dans certain cas, mais dans d’autre cela peut compliquer la gestion des erreurs car chaque méthode doit être suivi du traitement de l’erreur, ce qui généralement amène a une imbrication de if/switch pas très pratique, surtout qu’en général lorsqu’une erreur survient une grande partie du traitement doit être interrompue ! Les exceptions sont parfaites pour cela car elles permettent de faire des « sauts » tout en conservant un code assez propre
Imaginez un peu si vous deviez faire une vérification du code de retour après chaque méthode d’un InputStream lors de la lecture d’un fichier… On se retrouverait avec des imbrications de if pas possible
Pour moi cela peut être une solution dans certain cas bien précis, mais généralement je préfère les exceptions
A noter qu’avec les enums on perd le stacktrace ce qui est à la fois un avantage (le stacktrace est « couteux » à générer, ce qui peut être sensible si la fréquence des erreurs est élevée), mais également un désavantage certain (on perd une information très utile sur l’origine exacte du problème, ce qui doit être remplacer par une gestion plus détaillée des erreurs). Plus d’info : http://blog.developpez.com/index.php?blog=51&title=exception_et_performances&more=1&c=1&tb=1&pb=1
Sinon juste une remarque sur la redéfinition de toString() de l’enum, on pourrait également utiliser un attribut d’instance et un constructeur :
PASSWORD_EMPTY_OR_NULL("Password empty or null"), <br />
USER_EXISTS("User exists"), <br />
BAD_PASSWORD("Bad password"), <br />
INCORRECT_PASSWORD("Incorrect password"), <br />
UNKNOWN_USER("Unknow user"), <br />
NON_MATCHING_PASSWORD("Non matching password"), <br />
EXCEPTION("Exception"), <br />
EMPTY_EMAIL("Empty email"), <br />
BAD_EMAIL("Bad email"); <br />
<br />
/** Attribut d'instance représentant le message associé à la valeur de l'enum */ <br />
private final String text; <br />
<br />
/** Constructeur : */ <br />
private UserErrorCode(String text) { <br />
this.text = text; <br />
} <br />
<br />
@Override <br />
public String toString() { <br />
return this.text; <br />
} <br />
}
a++
Exceptions.
Si ton traitement est supposé retourner quelque chose, tu ne peux plus récupérer l’enum en retour.
Maintenant, tu pourrais avoir dans l’idée de ne pas faire de hiérarchie d’exceptions (sauf éventuellement sur la gravité) et d’y encapsuler l’enum (voire plusieurs si le contexte l’exige).
Salut.
Bon perso je fait du .NET mais le problème reste le même.
Dans mes dev, j’utilise les exceptions pour toute erreurs blocantes devant mettre fin au programme si non traité. Par exemple si un utilisateur ne rentre pas le bon mot de passe, s’il n’appartient pas au bon groupe Active Directory, pb de connexion à la base de données, etc, etc, etc.
Les enums je les laisse pour les erreurs de saisies (comme entrer un texte à la place d’un nombre), et de manière générale le GUI qui ne touche pas à la sécurité ni à la base du programme.
Voila c’est ma contrib du jour