à lancer, à retourner ou à errno?

Question

Je crée un système. Ce que je veux savoir, c'est si un message n'est pas supporté, que devrait-il faire? devrais-je jeter disant msg non pris en charge? devrais-je retourner 0 ou -1? ou devrais-je définir un errno (base-> errno_). Quelques messages je ne ferais pas attention s'il y avait une erreur (telle que setBorderColour). D'autres je voudrais (addText ou peut-être enregistrer si je crée un disque de sauvegarde).

Je veux savoir quelle est la meilleure méthode pour 1) coder rapidement 2) déboguer 3) étendre et maintenir. Je peux faire le débogage 3ème, c'est difficile de déboguer ATM mais c'est beaucoup de code manquant que je n'ai pas rempli dedans. Les bogues réels sont difficiles à corriger. Quel est le meilleur moyen de faire savoir à l'utilisateur qu'il y a une erreur?

Le système fonctionne quelque chose comme ça, mais pas exactement la même chose. Ceci est le style C et mycode a un tas de fonctions en ligne qui enveloppe setText (texte const char *) {à msg (ce, esettext, texte)

Base base2, base; 
base = get_root(); 
base2 = msg(base, create, BASE_TYPE); 
msg(base2, setText, "my text"); 
const char *p = (const char *)msg(base2, getText); 

Answer 1

Généralement, si c'est en C++, préférez les exceptions, sauf si les performances sont critiques ou si vous n'exécutez pas un environnement (par exemple une plate-forme intégrée) ne prenant pas en charge les exceptions. Les exceptions sont de loin le meilleur choix pour le débogage car elles sont très visibles lorsqu'elles se produisent et sont ignorées. De plus, les exceptions sont auto-documentées. Ils ont leur propre nom de type et généralement un message contenu qui explique l'erreur. Les codes de retour et errno requièrent des définitions de code séparées et une sorte de manière hors-bande de communiquer ce que les codes signifient dans un contexte donné (par exemple pages de manuel, commentaires). Pour coder rapidement, les codes de retour sont probablement plus faciles car ils n'impliquent pas potentiellement la définition de vos propres types d'exception, et souvent le code de vérification d'erreurs n'est pas aussi détaillé qu'avec des exceptions. Mais bien sûr, le grand risque est qu'il est beaucoup plus facile d'ignorer silencieusement les codes retour d'erreur, conduisant à des problèmes qui peuvent ne pas être remarqués bien après qu'ils se produisent, faisant du débogage et de la maintenance un cauchemar. Essayez d'éviter d'utiliser errno, car il est très sujet aux erreurs. C'est un global, donc vous ne savez jamais qui le réinitialise, et c'est définitivement pas thread sûr. Je viens de me rendre compte que vous vouliez dire une variable de membre errno et non le errno de style de C. C'est mieux parce que ce n'est pas global, mais vous avez encore besoin de constructions supplémentaires pour le rendre sûr (si votre application est multi-thread), et il conserve tous les problèmes d'un code de retour.

Answer 2

Personnellement quand il s'agit de graphiques de sortie, je me sens un silence échouer est bien. Cela ne fait que fausser votre image.

Les erreurs graphiques sont très faciles à repérer de toute façon.

Answer 3

Renvoyer un code d'erreur nécessite une certaine discipline car le code d'erreur doit être vérifié explicitement, puis transmis. Nous avons écrit un grand système basé sur C qui a utilisé cette approche et il a fallu un certain temps pour supprimer toutes les erreurs "perdues". Nous avons finalement développé quelques techniques pour attraper ce problème (comme stocker le code d'erreur dans un emplacement global de thread et vérifier au niveau supérieur pour voir que le code d'erreur retourné a correspondu au code d'erreur enregistré). La gestion des exceptions est plus facile à coder rapidement car si vous écrivez du code et que vous n'êtes pas sûr de savoir comment gérer l'erreur, vous pouvez simplement la laisser se propager vers le haut (en supposant que vous n'utilisez pas Java). avec des exceptions vérifiées). C'est mieux pour le débogage parce que vous pouvez obtenir une trace de pile où l'exception s'est produite (et parce que vous pouvez construire dans les gestionnaires d'exception de haut niveau pour attraper les problèmes qui auraient dû être attrapés ailleurs). C'est mieux pour la maintenance car si vous avez bien fait les choses, vous serez averti plus rapidement du problème.Cependant, il y a quelques problèmes de conception avec la gestion des exceptions, et si vous vous trompez, vous serez plus mal lotis. En résumé, si vous écrivez du code pour lequel vous ne savez pas comment gérer une exception, vous devriez le laisser se propager. Trop de codeurs piègent les erreurs juste pour convertir l'exception, puis la réimprimer, ce qui entraîne un code d'exception spaghetti qui perd parfois de l'information sur la cause initiale du problème. Cela suppose que vous avez des gestionnaires d'exceptions au niveau supérieur (points d'entrée).

Answer 4

Personnellement, j'ajouterais un errno à votre structure de base s'il s'agit d'un 'C' pur. Si c'est C++ je lancerais une exception.

Cela dépend de la façon dont ces erreurs sont «fatales». Est-ce que l'utilisateur a vraiment besoin de voir l'erreur, ou est-ce pour l'édification d'autres développeurs? Pour la maintenabilité, vous devez documenter clairement les erreurs qui peuvent se produire et inclure des exemples clairs de gestion des erreurs.