Discussion :

[souviron34]

En ce qui concerne le traitement des erreurs, je ne suis toujours pas convaincu....

Je ne cherche pas forcement a faire du code de geek, mais plutot le code le plus lisible et le plus maintenable.

Le mieux, c'est peut être d'expliquer les trois types de traitement d'erreurs que je connais.

.....

Et voila la version avec les goto

Tout d'abord je trouve la version 2 plus lisible et maintenable que la version 3, mais ça c'est question de goût.

Ensuite, voir ceci pour éliminer la version 3 :

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
 
static void Traite_Erreur ( int Error, FILE *fp_in, FILE *fp_out, char *buf )
{
	fprintf ( stderr, “Erreur %d”, Error );
// ou perror ()
 
    if (fp_out!=NULL)
       fclose (fp_out);      
    if (fp_in!=NULL) 
       fclose (fp_in);
    if (buf!=NULL)
	 free(buf);
}
 
………………
 
FILE *fp_in = NULL;
   FILE *fp_out = NULL;
   char* buf = NULL;
 
   fp_in = fopen (f_src, "r");
   if (fp_in == NULL) 
      {
	    Traite_Erreur ( fp_in_error, fp_in, fp_out, buf );
	    return 1 ;
	 }
 
   fp_out = fopen (f_des, "w") 
   if (fp_out == NULL) 
	{
	    Traite_Erreur ( fp_out_error, fp_in, fp_out, buf );
	    return 1 ;
	}
 
   buf = malloc(sizeof(char)*64);
   if (buf==NULL) 
	{
	    Traite_Erreur ( buf_error, fp_in, fp_out, buf );
	    return 1 ;
	}
 
    ...
 
    fclose (fp_out), fp_out = NULL;      
    fclose (fp_in), fp_in = NULL;
    free(buf);
 
    return 0;

Et Emmanuel j'aimerais bien que tu me montres un code où pour traiter les erreurs c'est nécessaire....

Enfin, quand dj.motte écrit :

Bonjour,

Souviron34, j'ai testé ton algo, ça ne trie rien !
Il y a une erreur quelque part ?

Salut.

je n'ai pas testé, mais c'est le PRINCIPE que je disais.. Et je ne vois pas pourquoi ça ne marcherait pas (ou alors c'est que ça ne devait pas marcher avant) : j'ai juste remplacé les goto et label par ce que ça faisait....

[Melem]

C'était juste pour rappeler qu'on peut faire des goto et même plus sans utiliser goto. Et merci pour les balises codes , j'ai pas remarqué avant.

[koala01]

C'était juste pour rappeler qu'on peut faire des goto et même plus sans utiliser goto. Et merci pour les balises codes , j'ai pas remarqué avant.

Sauf que, de manière générale, tu propose une solution qui est encore pire que le mal qu'elle est sensée combattre...

[souviron34]

Sauf que, de manière générale, tu propose une solution qui est encore pire que le mal qu'elle est sensée combattre...

pire est faible..... C'est plutôt à proscrire qu'il faudrait mettre...

[Melem]

J'aimerai savoir pouquoi vous dites que setjmp c'est mal (ou pire que mal ou encore pire que ca ou je sis plus) pourtant c'est simple d'usage, c'est portable (ANSI), et ca sert a plein de trucs notamment pour gérer les exceptions en C (en l'utilisant conjointement avec signal).

[koala01]

pire est faible..... C'est plutôt à proscrire qu'il faudrait mettre...

Disons que, meme si je suis pleinement de ton avis, j'avais décidé de laisser un certain libre arbitre à chacun en écrivant mon message

Je suis en effet de ceux qui pensent que l'exces nuit en toutes choses

Je reconnais, volontiers, que si l'on devait me demander de jeter un oeil à un code truffé de goto ou de jum/longjump, je demanderais à la personne de commencer par le reconcevoir en vue de les supprimer, mais dans tous les autres cas, ce qui ne m'atteint pas ne me regarde pas (du moins, du point de vue de la programmation) et donc... libre à qui veut d'utiliser les méthodes qu'il souhaite

[koala01]

En deux mots, simplement parce que tu ments au processeur...

Tu lui dit "la fonction machin (la fonction appelée par longjump), c'est pas la fonction, c'est juste une partie de la fonction en cours"...

Et qu'en informatique comme partout ailleurs, tous les mensonges finiront un jour ou l'autre par te retomber sur la tete

Surtout, si tu est un tout petit peu distrait, et que tu appelle par longjump une fonction qui renvoie un type différent que celui de la fonction dans laquelle se trouve le longjump...

En plus, ca brise entièrement le principe de la programmation structurée...

En effet, l'idée globale, c'est que

Code :

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

1
2
3
4
5
6
7
8
9
 
int mafonct()
{
   //du code
   if(test)
       mafonct2();
   //continuation apres mafonct2
   return 0;
}

alors que

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
 
int mafonct()
{
    //du code
    if(test)
       longjump(mafonct2());
    //tu pourrait croire que ca va continuer... et pourtant...
    //ca ne le fait pas, car regarde mafocnt2 ;)
    //encore du code
    return 1;
};
int mafonct2()
{
    //du code
    return 0;
}

Au moment meme, parce que tu vient de créer mafonct2 avant de creer mafonct, ca te parraitra limpide que ce qui suit le longjump n'est pas effectué...

Mais, dans deux mois, et comme tu auras défini mafonct2 dans une autre unité de traduction, tu auras oublié que mafonct2 contient un return, et tu croira que le code qui suit le longjump sera effectué... alors qu'il ne le sera pas...

Bref, lors de la reprise du code, tu sera tout étonné que le code qui suit le longjump ne soit pas effectué, et tu perdra un temps bete avant de réaliser "mais imbécile, mafonct2 renvoie une valeur et, du fait du longjump, c'est cette valeur là qui est renvoyée et qui fait sortir de mafonct"

[Médinoc]

En fait, la seule utilité de longjmp() est justement "en l'utilisant conjointement avec signal", et ce comme je l'ai dit, uniquement pour remonter dans une fonction appelante et un bloc de code "père".
Dans ce cas et dans ce cas seulement, les variables locales sont préservées.

Naturellement, longjmp() est absolument à proscrire en C++ (à supposer qu'il existe) car il saute tous les destructeurs.

[koala01]

C'est toujours le problème:

Pour chaque regle il est toujous possible de trouver l'unique exception qui ira confirmer la règle...

Et, si, de fait, longjump et goto peuvent s'avérer etre les seules possiblités cohérente dans des situations bien précises d'arriver à un résultat donné, il est tout à fait normal de les utiliser...

Par contre, l'éventualité de leur utilisation ne doit etre envisagée qu'en dernier recours, parce que, justement, on se trouve dans une situation dans laquelle les autres possibilités ne sont pas adaptées à la résolution cohérente du problème auquel on est confronté... et surtout, "à dose homéopatique".

[souviron34]

En fait, la seule utilité de longjmp() est justement "en l'utilisant conjointement avec signal", et ce comme je l'ai dit, uniquement pour remonter dans une fonction appelante et un bloc de code "père".
.

Même dans ce cas là, à mon avis c'est inutile.... Aurais-tu un exemple à fournir ?

[Médinoc]

Bien sûr, ce n'est pas pour répondre à su SIGALARM, mais il me semble que c'est la seule façon de traiter un SIGSEGV ou SIGDIV. Du moins, ça l'était sous DOS du temps de ma première année de BTS : Le prof nous avait dit que si on choisisait de traiter soi-même le signal, l'exécution reprenait juste avant l'erreur qui déclenchait donc à nouveau le signal (qui cette-fois-ci, n'était pas forcément redirigée vers le handler).
Dans cette perspective, le seul moyen d'éviter soit le crash, soit la boucle infinie était de remonter avec longjmp() jusqu'à un point où l'exécution n'allait pas irrévocablement vers le plantage (donc au minimum, il fallait remonter jusqu'à avant un if(), le if() en question étant typiquement celui effectué sur la valeur retournée par setjmp()).

[souviron34]

Médinoc a écrit :

mais il me semble que c'est la seule façon de traiter un SIGSEGV ou SIGDIV. Du moins, ça l'était sous DOS

je ne crois pas.. Mais j'aimerais avoir un exemple...

PS: DOS n'était pas réputé pour être conforme à C....

[Melem]

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
#include <stdio.h>
#include <signal.h>
#include <setjmp.h>

jmp_buf jmpbuffer;
void fpe_handler();

int main()
{
double x, inverse;
int stat;
signal(SIGFPE, fpe_handler); //Appeler fpe_handler en cas de Floating Point Exception

printf("Donnez-moi un nombre, je vais vous calculer l\'inverse.\n");

stat = setjmp(jmpbuffer);
scanf("%f", &x);
inverse = 1.0/x;

printf("L\'inverse de %f est %f.\n", x, inverse);

if (stat) printf("N\'oubliez plus qu\'une division par 0 ca n\'a aucun sens.\n");
return 0;
}

void fpe_handler(void)
{
signal(SIGFPE, fpe_handler); //Réarmer le signal
print("Impossible de diviser par 0. Recommencez.\n");
longjmp(jmpbuffer, 1);
}

Dans le main() il n'y a ni if ni boucle mais chaque fois qu'une division par 0 a lieu, le signal SIGFPE est généré. C'est à fpe_handler() qu'on a donné la charge de traiter cette exception. Pour retourner quelque part dans main(), on utilise longjmp(). Voilà un des interêts de sauter quelque part dans une fonction fille, mère ou tante comme certains le disent. Et tout ca c'est pas fesable avec du goto.

En plus ce qui est bien avec cette technique c'est qu'en plus des signaux prédéfinis, on peut bien sur en créer des nouveaux à l'aide de simples #defines. Pour générer un signal (comme le throw du C++ ou de Java), on utilise la fonction int raise(int sig). Et tout ca bien sur, ca marche aussi bien sous Windows que sous OS/2 ou UNIX/Linux parce que c'est standard.

Et dernière chose, longjmp() permet de sortir rapidement d'une fnction profondément imbriquée donc il n'est pas seulement utile qu'avec signal.

[Médinoc]

1. Ni fille ni tante : Mère uniquement, sinon la pile se retrouve avec un contenu indéfini.
2. Pour autre chose que signal(), je suis contre.

Note: On est d'accord, les variables des fonctions d'où est parti le signal ne sont pas détruites : Elles sont seulement irrémédiablement perdues. C'est pourquoi l'emploi de longjmp() est impensable en C++, les exceptions le remplaçant avantageusement.

[Melem]

[LIST=1]
On est d'accord, les variables des fonctions d'où est parti le signal ne sont pas détruites : Elles sont seulement irrémédiablement perdues.

Pas d'accord! Ce sont les variables allouées sur la pile (les variables automatiques) qui ne seront plus accessibles. Il suffit d'allouer les variables sur le tas pour qu'elles ne soient pas perdues lors du retour au contexte, malloc() fait l'affaire. Donc c'est faux que les variables locales à la fonction seront perdues. Et d'ailleurs ce ne sont pas les variables comme tu le dis qui peuvent être perdues mais leur contenu, leur référence étant toujours valide.

De toute manière le code c'était juste pour montrer comment utiliser setjmp avec signal donc très simplifié.

[Médinoc]

Des données allouées sur le tas ne sont pas des "variables locales", ni des variables du tout, d'ailleurs.
Une variable locale peut être un pointeur vers ces données allouées, par contre. Et le pointeur lui, est définitivement perdu.
Reste alors à espérer que ce n'était pas le seul pointeur vers ces données allouées, car si tous les pointeurs sont perdus avant que les données allouées soient détruites, ben... Elles seront alors perdues aussi.

[Melem]

Des données allouées sur le tas ne sont pas des "variables locales", ni des variables du tout, d'ailleurs.
Une variable locale peut être un pointeur vers ces données allouées, par contre.

Exact. Et c'est ce que je voulais dire. Il suffit d'utiliser une variable locale qui pointe des données sur le tas.

Et le pointeur lui, est définitivement perdu.

Faux. Les données allouées sur le tas ne sont pas détruites car ils n'ont aucun lien avec une pile d'éxecution d'une quelconque fonction.

Et si j'utilise par exemple une variable locale static, elle n'est non plus perdue lors du retour au contexte. Je dis bien : seules le contenu des variables locales automatiques sont perdues. Et à celà il y a au moins deux solutions très simples : malloc() ou classe static.

[Médinoc]

Bon,
je t'invite à relire ton livre de C pour réapprendre la différence entre des données allouées et le pointeur qui pointe dessus... (ou simplement à relire mon post)
--> Le pointeur dont je parlais n'était pas, lui, alloué sur le tas, que je sache. Seules les données pointées le sont.

PS: Une variable locale static n'est qu'une variable globale à portée réduite. Je sais bien qu'elle n'est pas sur la pile. Mais on n'a jamais parlé de variable static pour l'instant... Fallait-il que je précise explicitement "variables locales automatiques" ? N'es-tu pas capable de tirer du contexte le fait que c'était seulement des variables automatiques que je parlais ?

[Melem]

Bon, je t'invite à relire ton livre de C pour ...

Merci mais moi-même je suis entrain d'en écrire un en ce moment.

Fallait-il que je précise explicitement "variables locales automatiques" ?

Oui parce qu'une variable locale static c'est quand même une variable locale! Mais c'est pas tellement ca, Tu disias que les variables locales à la fonction sont irrémédiablement perdues, pourtant en les faisant pointer des données sur le tas, on ne perd absolument rien! Donc irrémédiable c'est tout à fait faux.

[Médinoc]

J'ai édité au-dessus pour préciser ma pensée.

Le pointeur pointe vers des données sur le tas, mais il est lui-même une variable locale automatique (tu vois, je précise! ). Donc, il (le pointeur) est irrémédiablement perdu lors du longjmp.

Et comme je l'ai dit plus haut (sans éditer cette fois), ce n'est pas un problème pour les données pointées s'il existe quelque part une copie dudit pointeur. Mais si c'était le seul, elles sont perdues aussi...