Hier, j'ai eu un débat animé avec un collègue sur la méthode à privilégier pour signaler les erreurs. Nous discutions principalement de l'utilisation des exceptions ou des codes d'erreur pour signaler les erreurs entre les couches ou les modules de l'application.
Quelles règles utilisez-vous pour décider si vous lancez des exceptions ou renvoyez des codes d'erreur pour le signalement des erreurs ?
Dans le domaine du haut niveau, les exceptions ; dans le domaine du bas niveau, les codes d'erreur.
Le comportement par défaut d'une exception est de dérouler la pile et d'arrêter le programme, si j'écris un script an et que je vais chercher une clé qui n'est pas dans un dictionnaire, c'est probablement une erreur, et je veux que le programme s'arrête et me fasse savoir tout cela.
Si, cependant, j'écris un morceau de code que je doit savoir le comportement de dans toutes les situations possibles, alors je veux des codes d'erreur. Sinon, je dois connaître toutes les exceptions qui peuvent être déclenchées par chaque ligne de ma fonction pour savoir ce qu'elle fera. L'exception qui a cloué au sol une compagnie aérienne pour avoir une idée de la difficulté de la tâche). Il est fastidieux et difficile d'écrire un code qui réagit de manière appropriée à chaque situation (y compris les situations malheureuses), mais c'est parce qu'écrire un code sans erreur est fastidieux et difficile, et non parce que vous passez des codes d'erreur.
Les deux sites Raymond Chen y Joel ont présenté des arguments éloquents contre l'utilisation d'exceptions pour tout.
J'ai trouvé deux de ces messages très intéressants (je n'ai pas lu le "et"), mais, en particulier pour le message de Raymond, il était difficile de dire dans quelle mesure il était vraiment agnostique du point de vue du langage. Je pense que vous pourriez écrire un argument tout aussi éloquent en faveur de l'utilisation des exceptions plutôt que des codes d'erreur.
+1 pour avoir souligné que le contexte a quelque chose à voir avec la stratégie de traitement des erreurs.
@Tom, Bons points, mais les exceptions sont garanties d'être attrapées. Comment pouvons-nous nous assurer que les codes d'erreur sont attrapé et non pas ignorés en silence à cause d'erreurs ?
Je préfère normalement les exceptions, car elles contiennent plus d'informations contextuelles et peuvent transmettre (lorsqu'elles sont correctement utilisées) l'erreur au programmeur de manière plus claire.
D'autre part, les codes d'erreur sont plus légers que les exceptions mais sont plus difficiles à maintenir. La vérification des erreurs peut être omise par inadvertance. Les codes d'erreur sont plus difficiles à maintenir car il faut tenir un catalogue avec tous les codes d'erreur et ensuite activer le résultat pour voir quelle erreur a été lancée. Les plages d'erreurs peuvent être utiles ici, car si la seule chose qui nous intéresse est de savoir si nous sommes en présence d'une erreur ou non, il est plus simple de vérifier (par exemple, un code d'erreur HRESULT supérieur ou égal à 0 est un succès et inférieur à zéro est un échec). Ils peuvent être omis par inadvertance car il n'y a pas de forçage programmatique pour que le développeur vérifie les codes d'erreur. D'autre part, vous ne pouvez pas ignorer les exceptions.
Pour résumer, je préfère les exceptions aux codes d'erreur dans presque toutes les situations.
"Les codes d'erreur sont plus légers que les exceptions" dépend de ce que vous mesurez et de la manière dont vous le faites. Il est assez facile de proposer des tests qui montrent que les API basées sur les exceptions sont beaucoup plus rapides.
@MooingDuck, C'est impossible, à moins que ces tests soient injustes/biaisés. Vous prétendez effectivement qu'il existe un environnement qui manipule les objets et les chaînes de caractères plus efficacement qu'il ne manipule les chiffres. Définitivement possible mais qui n'a rien de banal.
@smink, Bons points, mais comment aborder l'overhead des exceptions ? Les codes d'erreur ne sont pas seulement légers, ils sont essentiellement en apesanteur ; les exceptions ne sont pas seulement de poids moyen, elles sont lourd -des objets légers contenant des informations sur la pile et des choses diverses que nous n'utilisons pas de toute façon.
Je préfère les exceptions car
Votre quatrième point n'est pas juste : Un état d'erreur, lorsqu'il est converti en objet, peut également contenir du code pour vérifier si le fichier existe, s'il est verrouillé, etc. Il s'agit simplement d'une variante de stackoverflow.com/a/3157182/632951
"elles interrompent le flux de la logique". Les exceptions ont plus ou moins les effets suivants goto
Les exceptions sur les codes d'erreur, sans aucun doute. Les exceptions offrent les mêmes avantages que les codes d'erreur, mais aussi beaucoup plus, sans les inconvénients des codes d'erreur. Le seul inconvénient des exceptions est qu'elles entraînent un peu plus de frais généraux, mais à notre époque, ces frais généraux devraient être considérés comme négligeables pour presque toutes les applications.
Voici quelques articles qui discutent, comparent et opposent les deux techniques :
Vous y trouverez de bons liens qui vous permettront de poursuivre votre lecture.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
