10
votes

Règle générale: valeurs négatives ou positives pour le code d'erreur en C / C ++

J'ai mon propre type de retour et mes fonctions définies comme ceci: xxx

Cependant, je suis un peu incertain sur les valeurs de type d'erreur ici; Qu'est-ce que la standard / la meilleure pratique pour les valeurs des retours d'erreur dans C / C ++ - négatif ou positif ?

mise à jour: Merci pour vos réponses! Je cherchais des informations sur C et C ++, mais je me rendais aussi compte que cela soulève de bonnes questions sur la structure générale et les méthodes spécifiques à chaque langue (exceptions, codes d'erreur, retours d'objet, etc.).

c c++

1 commentaires

Vous posez des questions sur C ou C ++?

5 Réponses :

1
votes

Mieux vaut utiliser 0 (zéro) et non nul afin qu'ils puissent également être considérés comme booléens. Typiquement faux est 0, et vrai est autre chose.

10 commentaires

C'est ce qu'il fait et non zéro peut être négatif et positif ...

@Luchiangriggore en fait, il fait le contraire. Comme vous l'avez dit, les deux sont courants, mais c'est agréable de pouvoir également utiliser True / Faux.

Comment appelez-vous le contraire? "Utiliser 0 et non nul" par opposition à "en utilisant non-zéro et 0"?

@ Michaelkrelin-hacker je voulais dire qu'il utilise 0 comme succès, alors que je suggère que 0 est faux qui est opposé du succès.

@Brady, FAUX n'est pas contraire du succès, FAUX est le contraire de vrai. Mais maintenant je vois ce que tu veux dire. Saviez-vous que 99% des appels C-Bibliothèque standard et SysCalls renvoient 0 pour le succès et le code d'erreur sinon et sont très pratiques comme booléens?

@ Michaelkrelin-Hacker, oui, je savais que sur le retour 0 pour réussir en C, mais je pense que cette réponse serait meilleure pour C et C ++.

Je ne suis pas d'accord. Normalement, il y a une façon de réussir et de nombreuses raisons d'échec. Vous avez toujours droit à votre opinion, bien sûr, mais je pense toujours à quelle réponse à voter et ce n'est pas à vous (désolé;)).

Je suis d'accord. Avec Michael, c'est. La raison du 0 = statut de retour de réussite est celle-ci, il existe souvent de nombreux chemins différents à l'échec. Lorsqu'un échec survient, sachant que l'un des problèmes de myriades a eu lieu parfois du sida avec la récupération. Pas d'échec? Il suffit de bouger et de faire la prochaine chose à faire.

@ Michaelkrelin-hacker je vois votre point de vue. Il ne devrait y avoir qu'un seul succès (vrai) et de nombreux échecs, tous considérés comme faux et que je suggérais le contraire :)

Ouais. Vous suggérez le monde plein de succès et mais une façon d'échouer :) (comme pour le traiter comme un booléen, il serait une question de ! si nous ne sommes pas 't surtout intéressé par une défaillance - comme dans si (dostuff ()) renvoie non_zero_oh_no_while_day_stuff_code; ).
4 votes C ++: C'est une question de choix, j'ai vu les deux. Utilisez des exceptions! 8 commentaires "2." Fonctionne particulièrement bien pour ce C étiquette ;-) (Souhaite qu'il y ait eu un +0.5 option ;-)) @ Michaelkrelin-Hacker: C'est toujours un problème avec les questions C / C ++. Soit c'est c ou c'est c ++ ... @Matthieuum., Je dirais Souvent , pas TOUJOURS . La question ici n'est pas de savoir si elle est C ou C ++, mais plutôt que ce soit "C et C ++" ou "C ou C ++" ;-) @Matthieuum. Tout comme Stroustrup a dit: "Je ne sais aucune langue appelée C / C ++" :) Eh bien, il y a toujours SEH pour des exceptions dans C Ducks @ Michaelkrelin-hacker & matthieum s *** w la balise C / C ++. Je ne l'ai même pas remarqué. Vous pouvez mettre c ++ après 1. :) 2 votes Je ne sais pas à propos de c ... ... Mais en C ++, l'idée est de ne pas utiliser de codes d'erreur, en général. Je ne veux pas utiliser des exceptions mais un code d'erreur n'est pas vraiment trop informatif (manque de contexte, quelle est la valeur de file_not_found lorsque le nom du fichier est inconnu?). Dans les cas que je n'ai pas fait Utilisez des exceptions, j'ai eu tendance à préférer des objets d'erreur respectés. Un exemple pourrait être: xxx où vous obtiendrez un fichier ou une erreur, en fonction de ce qui se passe. 0 commentaires 3 votes Il y a plusieurs conventions à choisir: Microsoft utilise 0 = FALSE = Erreur pour la plupart de ses API de haut niveau. et laissez l'utilisateur rechercher l'erreur spécifique avec une fonction globale getlasterror () code> li> Microsoft utilise 0 = OK pour les API de niveau inférieur, comme le registre, l'audio ou la téléphonie. Tout cela renvoie un type similaire à celui hresult code>, contenant le code d'erreur spécifique. li> POSIX Fonctions Renvoyer un statut Renvoyer généralement -1 pour erreur et laissez l'utilisateur rechercher l'erreur via une variable globale errno code> li> Fonctions renvoyant un pointeur renvoie généralement null pour erreur li> C ++ STL Fonctions renvoie "fin" pour le statut comme "non trouvé". Les erreurs telles que «hors de mémoire» sont signalées à l'aide d'une exception. Li> ul> En général, il est plus important que vous utilisiez votre convention de manière systématique que celle que vous utilisez. p> BTW, quelques exemples de la manière de ne pas le faire dans l'en-tête de Microsoft Fichiers: P> #define S_OK ((HRESULT)0x00000000L) #define S_FALSE ((HRESULT)0x00000001L) 0 commentaires 17 votes Il s'agit vraiment de deux questions totalement différentes (versions C et C ++) déguisées comme une. en C ++ La réponse est simple: utilisez les valeurs de retour pour ... Valeurs de données renvoyées et utilisez des exceptions pour les cas d'erreur / d'exception. N'utilisez pas de valeurs de retour pour la vérification des erreurs dans Pure C ++ (API de bibliothèque C à C ++ est une histoire différente). en C, vous n'avez pas cette option, alors je suggérerais d'utiliser 0 pour le succès et les numéros négatifs pour les codes d'erreur. Cela laisse la flexibilité, si on le souhaite, d'utiliser des nombres positifs pour des informations de réussite supplémentaires (par exemple lire appels) 2 commentaires En ce qui concerne les exceptions en C ++, je remarquerais que cela ne signifie pas que tout à coup, toutes les méthodes devraient lancer . Par exemple: t const * myMap :: recherche (std :: string const & nom); est une méthode qui n'a pas besoin de lancer quand le nom n'a pas été trouvé; Il peut simplement retourner un pointeur nul. Je suis d'accord avec Matthieu. Des exceptions ne doivent être jetées que dans le cas d'événements exceptionnels, et non des résultats négatifs ordinaires d'une recherche, etc. Le lancement d'une exception est beaucoup plus lente que la valeur de retour de la fonction et même s'il n'est pas lancé le blocage {} Catch () Bloc-même et inclusion de Tous les machines de traitement des exceptions rendent le programme plus lent.

Articles qui pourrait vous intéresser : Que puis-je utiliser pour la conversion d'entrée au lieu de scanf? Comment puis-je calculer a * b / c lorsque a et b sont tous deux plus petits que c, mais que a * b déborde? Comment vérifier si un pointeur void (void *) est l'un des deux types de données? L'écran LCD affiche des caractères aléatoires (MPLAB)