Discussion :

[Loki13]

Bonjour,

je me pose une question concernant la validation des données et le traitement des erreurs.

Si j'ai une fonction qui valide les données entrantes et doit retourner une erreur dans le cas de données incorrectes, dans quels cas la fonction devrait lancer une erreur (ex.: throw new Exception("..."); ) et dans quels cas la fonction devrait seulement retourner un numéro d'erreur (ex.: return [#erreur]) devant être vérifié par l'appelant ?

Chaque pratique comporte ses avantages et ses inconvénients, lancer une erreur risque de faire crasher le programme si celle-ci n'est pas trappée correctement mais d'un autre côté ça nous assure que l'appelant ne pourra pas ignorer l'erreur...

Quelle est la meilleur pratique à utiliser selon vous ?

[hed62]

C'est une philosophie et une histoire de pratique plus qu'autre chose à mon sens... Mais je peux me tromper ^^

[hegros]

en complément à ce qui a été dis : dans le premier cas (throws new Exception) cela nous conduit à une conception oo obligatoirement tandis que le second cas non(retour de code erreur)

[mister3957]

Utiliser les exceptions demande d'être rigoureux sur leur utilisation (par exemple, un traitement pouvant en lancer doit indiquer lesquelles et dans quel cas).
Il est préférable de te faire une classe d'exception de base (si l'appelant ne souhaite juste savoir si ça a fonctionné ou pas) et la dériver en des exceptions spécifiques (si l'appelant peut traiter au cas par cas les soucis).

Ce que je fais, c'est que j'applique le pattern Composite, où une exception peut être conteneur d'une éventuelle exception d'origine du genre CEchecTraitementXException encapsule CDivideByZeroException.
Ensuite, je fais un try/catch dans ma fonction principale histoire que si personne n'a rattrapé une exception, ça puisse générer un petit rapport allant du plus haut niveau vers le plus bas niveau (pour que ça puisse aider autant l'uilisateur en regardant le haut niveau et le développeur qui ira chercher le bas niveau).

De cette manière, c'est moins frustrant d'avoir une boîte de dialogue avant de quitter qu'un crash brutale. Aussi, l'utilisateur peut faire copier/coller du rapport pour l'envoyer au support.
Dans ta classe de base des exceptions, tu peux proposer d'y ajouter des causes, des propositions de résolution (util si l'utilisateur est à l'origine du soucis, comme par exemple une valeur invalide dans son fichier de configuration, un fichier manquant etc...) et aussi des infos sur le contexte de déclenchement (les variables et leurs valeurs autour).

Pour finir, tu redéfinit le throw histoire d'ajouter automatiquement le fichier et la ligne de lancement de l'exception. Avec toutes ces infos, t'aura plus de facilité à cibler le soucis et le reproduire plutôt que de truffer ton code de point d'arrêt et relancer l'apply en checkant pas à pas le contexte.

Dernière avantage, en cas de pépin, l'utilisateur ne peut pas "s'en foutre" et continuer comme ci de rien était. Ha j'ai oublié encore un avantage, les exceptions ne te mobilisent pas la valeur de retour des traitements, ça te donne un code plus propre que sans cesse placer des paramètres de sortie et checker les valeurs de retour pour te retrouver dans un traitement de haut niveau qui te renvoi "faux" sans aucune explication sur ce qui a merdé.