Que devrais-je retourner pour des erreurs dans mes fonctions en C?

Question

Actuellement, je retourne -1 dans mes fonctions personnalisées en C si quelque chose ne va pas et 0 pour le succès. Par exemple, travailler avec une liste chaînée et certaines fonctions nécessite une liste non vide pour fonctionner correctement. Si la liste passée en argument est vide, je renvoie -1 (erreur) et 0 si elle n'est pas vide et que la fonction a fonctionné sans problème.

Devrais-je, peut-être, retourner 1 au lieu de -1?

Est-ce la façon habituelle de faire les choses en C ou recommandez-vous une approche différente?

Answer 1

Renvoie une valeur non nulle pour indiquer un échec. De cette façon, vous pouvez vous écrire des fonctions appels comme si:

if(func_call()) 
{ 
    doErrorHandling(); 
} 

Cette convention vous permettra d'utiliser une valeur !0 pour indiquer une erreur spécifique, et cela vous permettra d'utiliser une variable d'une manière uniforme. Ainsi, le corps du if montré dans l'exemple ci-dessus peut alors avoir une instruction switch pour traiter les erreurs spécifiques.

Vous pouvez le faire différemment - mais si vous choisissez de le faire tenir à une convention - l'API win32 (et d'autres API de je l'ai utilisé) mélanger et conventions de match, malheureusement.

Answer 2

Il existe de nombreux modèles - mais quoi que vous fassiez, faites-le de manière cohérente!

Si vous n'avez pas beaucoup de conditions défaillantes, utilisez simplement 0 pour l'erreur. En effet, les tests d'erreur sont écrits de manière simple:

if (!list_insert(...)) { handle_error; } 

Sinon réponses ci-dessous de zéro sont bonnes à utiliser ainsi que les réponses normales> = 0. Vous pouvez l'utiliser pour des fonctions telles que la longueur de la liste, qui dans des conditions normales, ne pas être négatif. Ou si vous voulez beaucoup de codes d'erreur (-1 - couinent, -2 - pas trouvé, -3 ..., ...)

Answer 3

Cela sonne bien. -1 est utilisé dans la fonction d'E/S, car une valeur de retour positive signifie généralement succès et nombre d'octets traités. Si vous avez plusieurs possibilités, une fonction peut mal tourner, vous pouvez alors renvoyer des entiers différents ou définir une variable d'erreur globale (errno est utilisée par la bibliothèque standard) pour contenir le code d'erreur.

En termes de style, je préfère ne pas retourner les codes d'état, car cela signifie mes fonctions ne peuvent pas (proprement) retourner quoi que ce soit d'autre. Au lieu de cela, je vérifierais l'entrée avant d'appeler la fonction. Mais ceci est subjectif et dépend du contexte.

Answer 4

Je suggère que vous trouviez un moyen de formater une chaîne entièrement informative et lisible par l'homme au point de l'erreur, où toutes les informations sont encore disponibles, et de concevoir un moyen de le faire descendre à travers le reste de la programme, à travers l'utilisateur, son téléphone mobile, à votre équipe de développement pour l'analyse.

Cela me semble comme une caractéristique importante de toute conception, si vous voulez produire de meilleurs logiciels plus rapidement. Tuer des informations d'erreur sur le chemin est un crime majeur, et le langage C n'est pas une excuse.