jeter, retourner ou errno?

Question

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

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

Le système fonctionne à peu près comme ceci mais pas exactement de la même manière. Ceci est un style C et mycode a un tas de fonctions en ligne qui enveloppent settext (const char * text) {en msg (this, esettext, text)

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

En règle générale, s'il s'agit de C ++, préférez les exceptions, à moins que les performances ne soient critiques ou que vous puissiez fonctionner dans un environnement (par exemple, une plateforme intégrée) qui ne prend 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 s'auto-documentent. Ils ont leur propre nom de type et généralement un message contenu qui explique l'erreur. Les codes de retour et errno exigent des définitions de code distinctes et un moyen quelconque de communiquer hors bande les sens des codes dans un contexte donné (pages de manuel, commentaires, par exemple).

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 des erreurs n'est pas aussi détaillé que pour les exceptions. Toutefois, le gros risque est qu’il est beaucoup plus facile d’ignorer silencieusement les codes de retour d’erreur, ce qui peut entraîner des problèmes qui ne seront peut-être pas remarqués bien après qu’ils se soient produits, ce qui rend le débogage et la maintenance un cauchemar.

Essayez de ne jamais utiliser errno, car il est très sujet aux erreurs. C’est un plan global, vous ne savez donc jamais qui le réinitialise, et c’est définitivement pas thread safe.

Modifier: je viens de comprendre que vous vouliez dire une variable membre errno et non l'errno de style C. C’est mieux, car ce n’est pas global, mais vous avez toujours besoin de nouvelles constructions pour le rendre thread-safe (si votre application est multi-threadée), et elle conserve tous les problèmes d’un code retour.

Answer 2

Le renvoi d'un code d'erreur requiert une discipline, car le code d'erreur doit être explicitement vérifié, puis transmis. Nous avons écrit un grand système basé sur C utilisant cette approche et il a fallu un certain temps pour supprimer tous les éléments "perdus". les erreurs. Nous avons finalement développé certaines techniques pour résoudre ce problème (comme stocker le code d'erreur dans un emplacement global de threads et vérifier au niveau supérieur que le code d'erreur renvoyé correspondait au code d'erreur enregistré).

La gestion des exceptions est plus facile à coder rapidement car si vous écrivez du code et que vous ne savez pas comment gérer l'erreur, vous pouvez simplement le laisser se propager vers le haut (en supposant que vous n'utilisez pas Java avec lequel vous devez vous occuper. exceptions vérifiées). Il est préférable de déboguer car vous pouvez obtenir une trace de la pile de l'emplacement de l'exception (et du fait que vous pouvez créer des gestionnaires d'exception de niveau supérieur pour résoudre les problèmes qui auraient dû être interceptés ailleurs). C’est mieux pour maintenir parce que si vous avez bien fait les choses, vous serez averti plus rapidement du problème.

Cependant, il existe des problèmes de conception liés à la gestion des exceptions, et si vous vous trompez, la situation s'en trouve dégradée. En bref, si vous écrivez du code que vous ne savez pas comment gérer une exception, vous devriez le laisser se propager. Trop de codeurs interceptent les erreurs uniquement pour convertir l'exception, puis la renverser, ce qui entraîne un code d'exception spaghetti qui perd parfois des informations sur la cause initiale du problème. Cela suppose que vous ayez des gestionnaires d'exceptions au niveau supérieur (points d'entrée).

Answer 3

Personnellement, en ce qui concerne la sortie des graphiques, j’estime qu’un échec silencieux convient. Cela rend juste votre photo fausse.

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

Answer 4

Personnellement, j'ajouterais un errno à votre structure de base si elle est pure 'C'. S'il s'agit de C ++, je lève une exception.

Cela dépend de la "fatalité" de ces erreurs. L'utilisateur a-t-il vraiment besoin de voir l'erreur ou est-ce l'édification d'autres développeurs?

Pour faciliter la maintenance, vous devez documenter clairement les erreurs pouvant se produire et inclure des exemples clairs de traitement des erreurs.