Comment gère-t-on les erreurs en C ?
Je souhaiterais écrire une petite bibliothèque pour m'en resservir dans d'autres programmes plus gros, mais je ne sais pas trop comment gérer intelligemment les erreurs à l'intérieur.
Par exemple, si j'ai une fonction renvoyant un entier, et que cette fonction, pour une raison ou pour une autre, ne peut pas calculer cet entier. Je peux me débrouiller pour qu'à l'intérieur de la fonction, un test soit fait et écrive à l'écran un message. Mais une fois revenu de cette fonction, comment savoir qu'il y a eu erreur et que le reste du programme ne peut pas se dérouler normalement ? Je peux renvoyer une fausse valeur, mais ça m'embête pour deux raisons :
- si ça se trouve, my_function peut renvoyer n'importe quel entier lorsqu'elle fonctionne bien, y compris le code d'erreur
- si deux fonctions ont des codes d'erreur différents, je risque de me mélanger les pinceaux en utilisant ma bibliothèque plus tard.
Y'a-t-il des bibliothèques standards et simples de gestion des erreurs ? J'ai regardé la glib, mais ça fait un peu grosse artillerie.
Je pensais définir une structure globale contenant la dernière erreur trouvée, mais c'est global et c'est moche.
Re: Comment gère-t-on les erreurs en C ?
Citation:
Envoyé par Le Furet
Je souhaiterais écrire une petite bibliothèque pour m'en resservir dans d'autres programmes plus gros, mais je ne sais pas trop comment gérer intelligemment les erreurs à l'intérieur.
Retourner un code d'erreur.
Par exemple : 0 = OK non 0 = ERR
Il est ensuite de la responsabilité du programmeur de faire le test. Du code de binbliothèque ne doit pas planter même en condition d'erreur, et ne doit pas non plus interrompre le fonctionnement du programme (sauf catastrophe irrécupérable. C'est rare).
Quelques exemples :
http://emmanuel-delahaye.developpez.com/clib.htm
Citation:
Par exemple, si j'ai une fonction renvoyant un entier, et que cette fonction, pour une raison ou pour une autre, ne peut pas calculer cet entier. Je peux me débrouiller pour qu'à l'intérieur de la fonction, un test soit fait et écrive à l'écran un message.
En mode debug uniquement. Dans la réalité, la notion d'ecran est floue, et rien ne garanti que stdout soit connecté à un écran (ni à un terminal). Mes libs tournent en embarqué ou sur PC sans distinction.
Citation:
Mais une fois revenu de cette fonction, comment savoir qu'il y a eu erreur et que le reste du programme ne peut pas se dérouler normalement ? Je peux renvoyer une fausse valeur, mais ça m'embête pour deux raisons :
C'est ce qu'on faut pour les pointeur, car la 'fausse valeur' est clairement définie par la norme (NULL). Pour un entier, c'est pas terrible. Il vaut mieux une erreur séparée. 2 méthodes :
Code:
1 2 3 4 5
|
int err = func();
if (!err)
{
} |
et
Code:
1 2 3 4 5 6
|
int err;
int val = func (&err);
if (!err)
{
} |
ces deux techniques sont extrèmement communes...
Citation:
Je pensais définir une structure globale contenant la dernière erreur trouvée, mais c'est global et c'est moche.
Ca peut se faire quand tu manipules des objets avec contexte (ADT, par exemple). Tu mets le code détaillé de la dernière erreur dans le contexte. C'est pas forcément plus pratique...
Re: Comment gère-t-on les erreurs en C ?
Citation:
Envoyé par Le Furet
Je souhaiterais écrire une petite bibliothèque pour m'en resservir dans d'autres programmes plus gros, mais je ne sais pas trop comment gérer intelligemment les erreurs à l'intérieur.
La manière la plus souple de gérer les erreurs dans une bibliothèque est d'appeler une fonction de callback enregistrée par l'utilisateur de la bibliothèque. Celle-ci peut alors faire ce qu'elle veut pour autant qu'on ait prévu assez d'information. Prévoir:- de documenter la possibilité ou non de quitter la fonction de callback par longjmp (si on dit que c'est possible, il y a des précautions à faire si la bibliothèque a un état), note que longjmp est très difficile à utiliser de manière robuste, c'est même quasiment impossible en dehors de cas très limité ou de s'être batit tout un environnement émulant les exceptions,
- la possibilité que la fonction de callback puisse demander de réessayer l'opération (pour autant que réessayer ait du sens)
- la possibilité que la fonction de callback puisse demander de retourner un code d'erreur
- la possibilité que la fonction de callback puisse demander un retour sans erreur avec un résultat qu'elle indique
- suivant le contexte il peut y avoir d'autres choses que le fonction de callback peut vouloir demander
La gestion des erreurs, ce n'est jamais simple, ce n'est jamais beau, ça prend parfois la plus grosse partie du code même si c'est jamais exécuté.