Discussion :

[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.

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.

[PRomu@ld]

Un sujet a été abordé il n'y a pas longtemps :

http://www.developpez.net/forums/viewtopic.php?t=433446

[Alexis75014]

Salut,

C'est l'inconvenient majeur du C, la gestion des erreurs, souvent on as l'impression que le code ressemble à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
si (traitement défavorable)
  fonction
sinon
 gestion erreur

donc comme tu vois tu test si tu peut appeller la fonction pour que celle ci se comporte correctement.

Une autre école consiste à utilisé une globale mais c'est carrement glauque. la technique glib c'est un marteau pour écraser une mouche mais si ton projet necessite une jolie gestion d'erreur ( compilateur, interpréteur ) c'est jouable.

Une autre solution est de renvoyer une structure résultat avec la valeur et l'erreur, un peu à la sauce que fait wait avec la gestion des valeurs de retour du process.

Une autre solution plus simple consiste à passer à un language qui supporte les exceptions ( bonheur !!! ).

Alexis

[Emmanuel Delahaye]

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

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.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
   int err = func();
   if (!err)
   {
   }

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
   int err;
   int val = func (&err);
   if (!err)
   {
   }

ces deux techniques sont extrèmement communes...

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...

[Emmanuel Delahaye]

C'est l'inconvenient majeur du C, la gestion des erreurs, souvent on as l'impression que le code ressemble à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
si (traitement défavorable)
  fonction
sinon
 gestion erreur

Je ne vois pas bien où est l'inconveniant.

[Jean-Marc.Bourguet]

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é.

[Le Furet]

Ca me semble un peu difficile à mettre en oeuvre.

Effectivement, un code de retour, c'est pas mal, mais dans ce cas, ma fonction ne peut rien renvoyer d'autre ? Je dois donc passer les valeurs de sorties des fonctions par référence ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
int my_function(int in, int *out) {
  if (in >= 0) {
    *out = ... ;
    return 0 ;
  }
  else {
    return 1 ; \\ erreur, le paramètre d'entrée doit être positif
  }
}

Dans un certain sens, ça m'arrange parce que j'écris souvent mes fonctions de cette forme-là et que ça m'embête de mélanger les deux styles, standard et par référence.

D'un autre côté, c'est pas léger léger...

[Emmanuel Delahaye]

Effectivement, un code de retour, c'est pas mal, mais dans ce cas, ma fonction ne peut rien renvoyer d'autre ? Je dois donc passer les valeurs de sorties des fonctions par référence ?

Pas de 'par références' en C... Par valeur uniquement, même si cette valeur est l'adresse d'une variable...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
int my_function(int in, int *out) {
  if (in >= 0) {
    *out = ... ;
    return 0 ;
  }
  else {
    return 1 ; \\ erreur, le paramètre d'entrée doit être positif
  }
}

Dans un certain sens, ça m'arrange parce que j'écris souvent mes fonctions de cette forme-là et que ça m'embête de mélanger les deux styles, standard et par référence.

D'un autre côté, c'est pas léger léger...

Pas trop le choix... On peut faire ça :

gérer l'erreur localement (err = ...), et à la fin (évidemment, sortie unique recommandée), mettre à jour la variable externe si nécessaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
if (out != NULL)
{
    *out = err;
}

Ca permet d'ignorer proprement l'erreur en passant NULL à la place de l'adresse de la variable...