Discussion :

[Torx26]

Bonjour

Je fais un petit programme qui prend en parametre un fichier texte contenant les données a traiter.

Pour la lecture des donnes, j'ouvre le fichier (open) lis les données et ferme le fichier (close), ceci par trois fonctions distinctes qui verifient qu'il n'y a pas d'erreur (ouverture, fermeture, etc) auquel cas je fais un EXIT_FAILURE.

Mon probleme est le suivant, existe t'il un moyen pour que, par exemple dans le cas du erreur a l'ouverture, on quitte le programme et non simplement la fonction, a partir de la fonction ayant "trouve" cette erreur ?

merci

[valefor]

je fais un EXIT_FAILURE

Vous faites un "return EXIT_FAILURE" ?

Essayez avec un "exit(EXIT_FAILURE)"

[Torx26]

Bonjour

Merci pour votre attention.
En cas de succes je retourne EXIT_SUCCES et en cas d'echec EXIT_FAILURE. Le type de retour de ma fonction est int hors exit(EXIT_FAILURE) est vu de type void.
msg du compilateur: void value not ignored as it ought to be.

[Kirilenko]

Il nous faudrait le code.
Tu es sûr que tu n'as pas un prototype de la fonction qui est différent ?

[souviron34]

existe t'il un moyen pour que, par exemple dans le cas du erreur a l'ouverture, on quitte le programme et non simplement la fonction, a partir de la fonction ayant "trouve" cette erreur ?

Bonjour

outre le fait que ce n'est pas une bonne pratique - la règle générale est de remonter l'erreur niveau par niveau jusqu'au premier - l'utilisation d'exit() un peu partout dans des fonctions est très fortement déconseillé.

Une solution peut consister à utiliser la fonctionalité atexit pour enregistrer des fonctions à appeler lors de la sortie, et éventuellement dans ce cas faire à l'intérieur un exit(), ce qui concentre en un seul point le code..

Enfin, ton erreur vient, comme on l'a signalé, d'une erreur dans la déclaration de main / ou d'oubli d'inclusion de stdlib.h

Code C :

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

1
2
3
int main ( int argc, char **argv )
[
}

ou

Code C :

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

1
2
3
int main ( void )
[
}

[valefor]

Le type de retour de ma fonction est int hors exit(EXIT_FAILURE) est vu de type void.
msg du compilateur: void value not ignored as it ought to be.

N'auriez vous pas écrit

Code :

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

return exit(EXIT_FAILURE)

par hasard ?

Il faut écrire

Code :

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

exit((EXIT_FAILURE)

tout court. Pas de return.

Et concernant l'avis de souviron34, je ne suis pas aussi catégorique... A mon avis (ce n'est donc pas à prendre comme une généralité), ne pas utiliser exit est une peur qui pourrait venir du monde windows. Par exemple il me semble que quand on fait un exit sous windows, toutes les ressources ne sont pas bien "nettoyées". Encore récemment, j'ai vu une socket qui ne se fermait pas bien ce qui avait un impact sur le code qui tournait à l'autre bout...

Sous Linux, les fichiers sont fermés, les ressources mémoire libérées... bref, je ne vois pas ce que l'on aurait besoin de faire de plus, manuellement...

[souviron34]

Et concernant l'avis de souviron34, je ne suis pas aussi catégorique... A mon avis (ce n'est donc pas à prendre comme une généralité), ne pas utiliser exit est une peur qui pourrait venir du monde windows. Par exemple il me semble que quand on fait un exit sous windows, toutes les ressources ne sont pas bien "nettoyées". Encore récemment, j'ai vu une socket qui ne se fermait pas bien ce qui avait un impact sur le code qui tournait à l'autre bout...

Sous Linux, les fichiers sont fermés, les ressources mémoire libérées... bref, je ne vois pas ce que l'on aurait besoin de faire de plus, manuellement...

Je n'ai jamais (quasi) programmé sous Windows

Ce n'est pas une peur du tout, c'est une bonne pratique, au même titre que proscrre, sauf cas très très particulier, le goto, car cela amène à du code "spagetti", où le (futur) lecteur ne peut pas suivre le flux du code sans s'arracher les cheveux...

Lorsqu'un logiciel fait plusieurs milliers, voire dizaines ou centaines de milliers de lignes, ne pas avoir de "point central" de sortie est une abomination...

Cela n'a rien à voir avec Windows ou pas.. C'est du développement logiciel..

je ne vois pas ce que l'on aurait besoin de faire de plus, manuellement...

ça peut être fermer des ressources non systèmes (une base de données par exemple), enlever des locks, libérer ou détruire des fichiers temporaires, envoyer un message, stocker un drapeau dans une BD, fermer des sockets...

Etant donné que tout développeur dont c'est le métier va finir un jour ou l'autre par travailler sur des sources complexes, et de plus de 100 lignes, acquérir les bons réflexes le plus tôt possible est le plus sain..

Même une erreur d'allocation mémoire n'est pas fatale.. Un logiciel peut tès bien continuer, et retenter un peu plus tard.. Avec un exit() c'est foutu...

D'autant plus que quand même beaucoup de logiciels doivent être 24/24, ne jamais s'arrêter...

[Thierry Chappuis]

Je suis de ceux qui sont d'accord avec souviron34 sur le fait de remonter l'erreur . C'est à la fonction appelante de décider quoi faire en cas d'erreur, et non à la fonction où c'est produite l'erreur. Si la fonction appelante n'est pas main(), on remonte plus haut jusqu'à ce que quelqu'un traîte l'erreur. En dernier ressort, main() peut éventuellement quitter l'application. En général, je n'autorise pas d'autre fonction que main() à terminer l'exécution du programme.

En renvoyant un code d'erreur à la fonction appelante plutôt qu'en quittant brusquement le programme, pour permettez à la fonction appelante de faire quelque chose d'intelligent avec cet erreur: réessayer plus tard, libérer des ressources après sauvegardes dans un fichier et réessayer, ou en désespoir de cause sauver ce qui peut l'être et remonter l'erreur jusqu'à main().

On voit beaucoup de code pour débutant qui, p.ex., quitte le programme en cas d'échec de la fonction malloc(). Il y a pourtant souvent des alternatives qui pourront être mises en oeuvre par la fonction appelante.

Avec mes meilleures salutations

Thierry

[Bktero]

Je partage également cette vision. De même, j'essaye autant que possible d'avoir un seul point de sortie (return) dans des fonctions complexes. Le flot d'exécution est plus simple à suivre et si des traitements doivent être faits avant de terminer la fonction, ils sont ainsi centralisés.

Je viens d'ailleurs de découvrir la fonction atexit, ça peut être bien utile !

[Kirilenko]

De même, j'essaye autant que possible d'avoir un seul point de sortie (return) dans des fonctions complexes. Le flot d'exécution est plus simple à suivre et si des traitements doivent être faits avant de terminer la fonction, ils sont ainsi centralisés.

Je plussoie, mais en contradiction avec un point cité plus haut : cela n'est pas toujours compatible avec la réduction irrémédiable de l'utilisation des goto. Il est donc parfois plus intéressant de créer un seul point de sortie, mais de diriger par des goto les conditions d'erreur.
Je ne suis pas fanatique des sauts inconditionnels, mais cela peut parfois être utile.

[souviron34]

cela n'est pas toujours compatible avec la réduction irrémédiable de l'utilisation des goto.

l'utilisation (ou non) de goto n'a rien à voir ici...

donne-moi un exemple où on a besoin de goto pour faire ça... et qui rendrait la "politique" ci-dessus incompatible..

En 22 ans de C je n'ai jamais utilisé un seul goto...

[Kirilenko]

Je n'ai pas dit « indispensable », j'ai simplement évoqué que cela pourrait plus pratique syntaxiquement, ce qui paraît pourtant surprenant au premier abord (goto rendant le plus souvent ses codes illisibles). Exemple de recodage de la fonction getdelim (pas le meilleur exemple, mais j'ai trouvé que ça sous la main).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
ssize_t
getdelim (char **lineptr, size_t *n, int delimiter, FILE *fp)
{
  ssize_t result;
  size_t cur_len = 0;
 
  if (lineptr == NULL || n == NULL || fp == NULL)
    {
      errno = EINVAL;
      return -1;
    }
 
  flockfile (fp);
 
  if (*lineptr == NULL || *n == 0)
    {
      *n = 120;
      *lineptr = malloc (*n);
      if (*lineptr == NULL)
	{
	  result = -1;
	  goto unlock_return;
	}
    }
 
  for (;;)
    {
      int i;
 
      i = getc (fp);
      if (i == EOF)
	{
	  result = -1;
	  break;
	}
 
      /* Make enough space for len+1 (for final NUL) bytes.  */
      if (cur_len + 1 >= *n)
	{
	  size_t needed_max =
	    SSIZE_MAX < SIZE_MAX ? (size_t) SSIZE_MAX + 1 : SIZE_MAX;
	  size_t needed = 2 * *n + 1;   /* Be generous. */
	  char *new_lineptr;
 
	  if (needed_max < needed)
	    needed = needed_max;
	  if (cur_len + 1 >= needed)
	    {
	      result = -1;
	      goto unlock_return;
	    }
 
	  new_lineptr = realloc (*lineptr, needed);
	  if (new_lineptr == NULL)
	    {
	      result = -1;
	      goto unlock_return;
	    }
 
	  *lineptr = new_lineptr;
	  *n = needed;
	}
 
      (*lineptr)[cur_len] = i;
      cur_len++;
 
      if (i == delimiter)
	break;
    }
  (*lineptr)[cur_len] = '\0';
  result = cur_len ? cur_len : result;
 
 unlock_return:
  funlockfile (fp);
  return result;
}

[souviron34]

Ce code est une belle démonstration de ce qui ne faut pas faire :

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
ssize_t
getdelim (char **lineptr, size_t *n, int delimiter, FILE *fp)
{
  ssize_t result=0;
  size_t cur_len = 0;
 
  if (lineptr == NULL || n == NULL || fp == NULL)
    {
      errno = EINVAL;
      return -1;
    }
 
  flockfile (fp);
 
  if (*lineptr == NULL || *n == 0)
    {
      *n = 120;
      *lineptr = (char *) malloc (*n);
    }

   if (*lineptr != NULL )  
 {
   for (;;)
    {
      int i;
 
      i = getc (fp);
      if (i == EOF)
	{
	  result = -1;
	  break;
	}
 
      /* Make enough space for len+1 (for final NUL) bytes.  */
      if (cur_len + 1 >= *n)
	{
	  size_t needed_max =
	    SSIZE_MAX < SIZE_MAX ? (size_t) SSIZE_MAX + 1 : SIZE_MAX;
	  size_t needed = 2 * *n + 1;   /* Be generous. */
	  char *new_lineptr;
 
	  if (needed_max < needed)
	    needed = needed_max;
	  if (cur_len + 1 >= needed)
	    {
	      result = -1;
	      break ;
	    }
 
	  new_lineptr = (char *) realloc (*lineptr, needed);
	  if (new_lineptr == NULL)
	    {
	      result = -1;
	      break ;
	    }
 
	  *lineptr = new_lineptr;
	  *n = needed;
	}
 
      (*lineptr)[cur_len] = i;
      cur_len++;
 
      if (i == delimiter)
	break;
    }
  ]

  if ( result == 0 )
  {
    (*lineptr)[cur_len] = '\0';
    result = cur_len ? cur_len : result;
  }

  funlockfile (fp);
  return result;
}

Et encore, j'ai été au plus vite, mais je ne vais pas approfondir..

Ce code contient encore plein de choses à améliorer, mais ne nécessite strictement pad de goto...

[Kirilenko]

Je ne suis pas l'auteur du code hein...

[souviron34]

ce qui prouve que le code libre contient bien des âneries...

[Thierry Chappuis]

On rencontre ce type de gestion d'erreur assez souvent, et pas que sur du logiciel libre. Pour beaucoup, il semble que cela soit une des rares utilisation acceptée de goto. Cela évite parfois de nombreux tests imbriqués qui conduisent à des indentations importantes. Personnellement, je ne suis pas fan.

Thierry

[anacharsis]

Même une erreur d'allocation mémoire n'est pas fatale.. Un logiciel peut tès bien continuer, et retenter un peu plus tard.. Avec un exit() c'est foutu...

D'autant plus que quand même beaucoup de logiciels doivent être 24/24, ne jamais s'arrêter...

;-) j'espère que tu n'est pas concepteur de logiciel de régulation de trafic aérien ...
un programmeur n'a pas le droit de faire des erreurs d'allocations mémoire. un débutant oui.
ces programmes faux qui tournent 24/24 me font froid dans le dos. comme ses compilateurs qui génèrent des codes qui ne libèrent pas toutes les resources ouvertes à leur demande quand le programme se termine. mais je dois vivre avec ...

A+

[Thierry Chappuis]

Qu'est ce qui est faux dans l'intention de se récupérer d'une erreur d'allocation autrement qu'en quittant le programme?

Thierry

[Bktero]

Cela évite parfois de nombreux tests imbriqués qui conduisent à des indentations importantes. Personnellement, je ne suis pas fan.
Thierry

C'est pour ça que j'ai dit dans la mesure du possible, car trop de tests imbriqués tuent aussi la lisibilité.

Tu n'es pas fan des GOTO ou des indentations importantes ?

[souviron34]

;-) j'espère que tu n'est pas concepteur de logiciel de régulation de trafic aérien ...

Eh si justement

un programmeur n'a pas le droit de faire des erreurs d'allocations mémoire. un débutant oui.

On ne parlait pas d'erreur d'allocation, mais d'allocation qui échoue..

ces programmes faux qui tournent 24/24 me font froid dans le dos

Moi, ce qui me fait froid dans le dos, c'est quand un enseignant (ce que tu proclames être) d'une part ne sait pas lire, et d'autre part enseigne des absurdités...


Une allocation qui échoue parce qu'il n'y a pas de place mémoire disponible au temps t peut réussir au temps t' ...

Un vrai programme robuste 24/24 doit être capable de se débrouiller sans planter si une allocation a échoué..

Il est donc essentiel de remonter l'erreur, afin d'adopter des stragégies diverses à la suite.

Une vraie programmation robuste consiste à toujours vérifier avant de s'en servir si un pinteur est null ou non, d'avoir le nombre exact d'éléments alloués et non pas le nombre hypothétique, etc etc...

Alors oui le code est plus long.. c'est plus pénible à écrire..

Un code écrit défensivement est environ le double en longueur, mais en éxécution non (puisque l'essentiel du code supplémentaire est inclus dans des tests : c'est en général le même style de choses que la libération de tableaux à N dimensions) **


Quant à l'argument de "gestion d'erreur" mentionné par Thierry Chapuis, je n'en ai toujours pas eu de preuve...

A la base c'est à mon avis une (très grave) erreur de conception...
(sans même avoir à aller aux extrêmes des "normes" disant un if par fonction)

Je n'ai jamais vu d'exemples où l'avantage était évident..

Ce qui est différent du cas du break....



** : note

Par exemple, l'allocation d'un élément supplémentaire dans une structure de N tableaux peut amener à O(N2) lignes de code défensif : pour chaque tableau , si l'allocation échoue, on doit libérer les éléments correspondants des tableaux précédents.. Si ces tableau sont des tableau à plusieurs dimensions, il faut ajuster.. Ce qui peut induire une (très longue) fonction d'allocation en terme de code écrit, mais est 100% robuste..