Discussion :

[dabeuliou]

Bonjour à tous,

Après quelques recherches sur internet, je me pose toujours une question sur le mécanisme de gestion des exceptions dans les constructeurs décrit dans le cours de Christian Casteyde : http://www.developpez.com/c/megacours/x3910.html

J'ai considéré le cas suivant :

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
 
#include <iostream>
 
using namespace std;
 
void Print(const string &inStr)
{
        cout << inStr << endl;
}
 
struct A
{
        double *valA;
 
        A()
        try : valA(0)
        {
                valA = new double;
                Print("A::A()");
                throw new string("Exception !");
        }
        catch(...)
        {
                Print("Catch de A");
                delete valA; valA = 0; // Pas de problème: valA vaut 0 ou pointe sur une zone mémoire correctement allouée.
        }
};
 
struct B : public A
{
        double *valB;
 
        B()
        try : valB(0), A()
        {
                valB = new double;
                Print("B::B()");
        }
        catch(...)
        {
                Print("Catch de B");
                if(valB) Print(string("valB != 0")) ;
                else Print(string("valB == 0"));
 
                delete valB; valB = 0; // Aïe, aïe ! Dans ce cas, valB n'a pas encore été initialisé à 0, il pointe vers une zone mémoire farfelue !
        }
};
 
int main()
{
        try
        {
                B b;
        }
        catch(string *inE)
        {
                Print(*inE);
        }
}

A l'exécution, on obtient ceci :

Code :

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

1
2
3
4
5
6
 
A::A()
Catch de A
Catch de B
valB != 0
Exception !

Dans cet exemple, le code du constructeur de B ne sera jamais exécuté et le pointeur valB n'est jamais initialisé à zéro. Pourtant, le catch de B sera exécuté. Or j'aimerais pouvoir libérer le membre valB dans ce catch. Je ne peux pas me contenter d'appeler "delete valB" sans me poser de question puisque dans le cas de cet exemple, valB n'est pas initialisé à zéro !

En fouillant dans la FAQ, j'ai vu qu'une autre méthode (à laquelle j'avais pensé) y était proposée : http://c.developpez.com/faq/cpp/?pag...S_constructeur
Cette second méthode marche bien : le catch d'une classe est appelé si et seulement si le constructeur de cette classe a été exécuté (éventuellement partiellement). Les classes dérivées ne seront pas averties de l'exception.

Je me pose donc la question naturelle suivante : le C++ propose un mécanisme censé être adapté aux exceptions dans les constructeurs mais il ne me paraît pas utilisable. Est-ce que je l'utilise mal ? Comment procédez-vous pour gérer les exceptions dans les constructeurs ?

Merci pour vos avis !

[MatRem]

Je n'ai peut être pas compris ce que tu veux faire, mais pourquoi dans le constructeur de B, tu utilises le try pour englober l'appel a A().
En effet, si l'appel à A() à echoué, pourquoi entrer dans B()?

En faisant ça comme ça le problème de libération de mémoire est réglé:

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
#include <iostream>
 
using namespace std;
 
void Print(const string &inStr)
{
        cout << inStr << endl;
}

struct A
{
        double *valA;
 
        A()
        try : valA(0)
        {
                valA = new double;
                Print("A::A()");
                throw string("Exception !");
        }
        catch(...)
        {
                Print("Catch de A");
                delete valA; valA = 0; // Pas de problème: valA vaut 0 ou pointe sur une zone mémoire correctement allouée.
        }
};

struct B : public A
{
        double *valB;
 
        B()
        : valB(0), A()
	{
		try {
			valB = new double;
			Print("B::B()");
		}
		catch(...)
		{
			Print("Catch de B");
			if(valB) Print(string("valB != 0")) ;
			else Print(string("valB == 0"));
	
		delete valB; valB = 0; // Aïe, aïe ! Dans ce cas, valB n'a pas encore été initialisé à 0, il pointe vers une zone mémoire farfelue !
		}
	}
};
 
int main()
{
        try
        {
                B b;
        }
        catch(const string & inE)
        {
                Print(inE);
        }
}

De plus il me semble que si tu déclenches une exception avec new, il faudrait libérer la mémoire, hors ça ne doit pas toujours être évident.
C'est pourquoi je n'ai pas utiliser le new.

[dabeuliou]

Ce que tu proposes est effectivement un moyen qui marche. Et je l'ai cité dans mon premier post : c'est ce qui est proposé dans la FAQ. Cette méthode présente un inconvénient : il faut penser à relancer l'exception avec un throw à la fin du catch pour que l'exception remonte dans les classes dérivées, sinon il y aura des fuites de mémoire pas forcément faciles à détecter. Dans le cas de la manière "standard", l'exception est automatiquement relancée.

Ma question est donc de savoir à quoi sert le mécanisme proposé par le C++, lequel consiste entre autres à placer le try en tête du constructeur. S'il existe, il doit y avoir une raison et elle m'échappe.

[loufoque]

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
struct A
{
        double *valA;
 
        A()
        try : valA(0)
        {
                valA = new double;
                Print("A::A()");
                throw string("Exception !");
        }
        catch(...)
        {
                Print("Catch de A");
                delete valA; valA = 0; // Pas de problème: valA vaut 0 ou pointe sur une zone mémoire correctement allouée.
        }
};

C'est pas bon ça.
Si new lève une exception, alors il ne faut pas libérer la mémoire, tout simplement parce qu'elle n'a pas été allouée. Enfin bon delete fonctionne avec 0 donc ça marche.

Pareil dans le second cas.

[dabeuliou]

Evidemment que dans l'exemple que je cite, l'appel à delete n'a pas vraiment d'intérêt mais il s'agit d'un exemple pour présenter le problème. Il est en tout cas inoffensif à condition que les pointeurs pointent vers 0 ou vers une zone mémoire allouée.

En tout cas, s'il y avait plusieurs membres alloués dynamiquement dans A et dans B, il serait bien nécessaire d'appeler delete sur les membres. Les puristes diront qu'appeler delete sur le dernier membre alloué est inutile puisque si une exception est levée, c'est qu'il n'a pas été alloué mais ce genre de discussion ne fait pas avancer le schmilblic.

C'est étrange, j'ai l'impression que personne ne ressent ce problème avec les exceptions dans les constructeurs, c'est pourtant un problème ultra fréquent, non ? Peut-être que ma manière de présenter le problème est confuse, alors je pose la question autrement : "Comment faites-vous pour libérer la mémoire allouée dans les constructeurs ?"

[JolyLoic]

Ce que tu proposes est effectivement un moyen qui marche. Et je l'ai cité dans mon premier post : c'est ce qui est proposé dans la FAQ. Cette méthode présente un inconvénient : il faut penser à relancer l'exception avec un throw à la fin du catch pour que l'exception remonte dans les classes dérivées, sinon il y aura des fuites de mémoire pas forcément faciles à détecter.

Faux. Dans ce cas, une exception est forcément relancée à la fin du catch.

[JolyLoic]

As-tu lu http://www.gotw.ca/publications/mill13.htm ?

[dabeuliou]

Faux. Dans ce cas, une exception est forcément relancée à la fin du catch.

J'insiste : la solution proposée par MatRem inclut le try/catch à l'intérieur du code du constructeur de B, comme dans une méthode classique. Dans ce cas, l'exception n'est PAS relancée automatiquement (ce qui parait logique à la réflexion).

As-tu lu http://www.gotw.ca/publications/mill13.htm ?

Non et je vais le lire de ce pas. Merci pour le lien.

[JolyLoic]

J'insiste : la solution proposée par MatRem inclut le try/catch à l'intérieur du code du constructeur de B, comme dans une méthode classique.

Tu as raison d'insister, j'avais supposé à tort que le lien, que je n'ai pas suivi, parlait des blocs try/catch au niveau du constructeur, et non à l'intérieur de celui-ci.

[MatRem]

Une solution consisterai peu être à ne pas générer la même classe d'exception dans A et dans B.
Ainsi dans B si tu captes une exception de la classe A, il ne sera pas nécessaire de "nettoyer".

A vrai dire je ne connaissais pas ce type de bloc try dans le constructeur, mais je n'en vois pas bien l'utilité, si ce n'est d'automatiquement relancer l'exception... ce qui n'est pas toujours nécessaire...
Par contre on peut bien voir le problème qui peut se poser lors de l'heritage en mettant l'appel au constructeur de la classe de base dans le try, grace à ton exemple .

A mon avis, on dirait qu'il ne faut pas l'utiliser tout le temps, mais ça peut être pratique de temps en temps.

ps:
loufoque < effectivement j'ai pas géré l'exception que pouvait généré new. C'est pas du joli code .

[loufoque]

Je vais reprendre ton code.

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
#include <iostream>
 
using namespace std;
 
void Print(const string &inStr)
{
        cout << inStr << endl;
}
 
struct A
{
        double *valA;
 
        A() : valA(new double)
        {
                Print("A::A()");
 
                try // on peut éviter ce bloc try/catch avec rethrow en initialisant valA après
                {
                        throw string("Exception !"); // si on suit les bonnes pratiques on lève par valeur
                }
                catch(...)
                {
                        delete valA;
                        throw;
                }
        }
 
        ~A()
        {
                delete valA;
        }
};
 
struct B : public A
{
        double *valB;
 
        B() : A(), valB(new double)
        {
                Print("B::B()");
        }
 
        ~B()
        {
                delete valB;
        }
};
 
int main()
{
        try
        {
                B b;
        }
        catch(const string& inE) // d'après les bonnes pratiques on attrape par référence
        {
                Print(inE);
        }
}

Il n'y aucune raison d'avoir des try/catch dans B...
À moins que tu ne veuilles changer le type d'exception ?

[dabeuliou]

C'est un vieux sujet mais je voudrais répondre aux remarques de loufoque :
- [troll]que les "bonnes règles" préconisent de lever une exception par valeur ou par new, peu importe. Il n'y a aucun problème technique à lever des exceptions par new et le sujet n'est pas là.[/troll]
- il n'y a aucune raison de mettre un catch dans B dans mon exemple, c'est vrai et mon exemple n'est effectivement pas très parlant. Ce que je cherche à voir, c'est comment procéder pour libérer la mémoire dans le cas général d'une exception dans un constructeur d'une classe à un niveau quelconque d'une hiérarchie de dérivation. Imaginons qu'une classe C dérive de B. Si des membres sont alloués dynamiquement dans B, la nécessité du catch si l'exception est levée dans B devient évidente. Mais le problème, c'est que si l'exception est levée dans A on passera tout de même dans le catch de B. D'où la difficulté de coder un traitement général et simple dans ce catch de B : on ne peut pas se contenter d'un delete sur les membres de B qui risquent de ne pas avoir été initialisés. Il faut dégainer une usine à gaz pour détecter que l'exception est issue de A ou de B, j'ai mal à la tête rien que d'y penser.

D'où ma conclusion que ce mécanisme introduit dans le langage n'est jamais utilisable ou tout au moins qu'il n'apporte aucune simplification de codage par rapport à un classique try/catch à l'intérieur du constructeur, comme on le ferait dans une méthode classique.

[loufoque]

Tu prétends donc que si la base fait une allocation dynamique mais que la classe dérivée lève une exception alors cette mémoire ne sera pas libérée.
C'est bien entendu faux, encore heureux. Le destructeur de la base sera alors appelé.

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
#include <iostream>
#include <ostream>
 
struct Foo
{
	int* val;
 
	Foo() : val(new int)
	{
	}
 
	~Foo()
	{
		delete val;
		std::cout << "pas de souci" << std::endl;
	}
};
 
struct Bar : public Foo
{
	Bar() : Foo()
	{
		throw 1;
	}
};
 
int main()
{
	try
	{
		Bar bar;
	}
	catch(...)
	{
		std::cout << "une exception a été levée" << std::endl;
	}
}

Ce serait quand même pas mal d'apprendre les bases du langage avant de raconter tout un tas de conneries.

[dabeuliou]

Tu prétends donc que si la base fait une allocation dynamique mais que la classe dérivée lève une exception alors cette mémoire ne sera pas libérée.

Non, à force on se mélange un peu dans les explications : je veux dire que si l'exception est levée dans A, alors il ne faut rien faire dans B. Par contre, si l'exception est levée dans B alors que des membres de B ont déjà été alloués dynamiquement, il faut libérer la mémoire de ceux-ci.

Le catch de B est donc utile si l'exception peut provenir de B mais son codage est difficile car il ne doit rien faire si l'exception provient de A. Et savoir où a été levée l'exception est à mon avis impossible sans se compliquer la vie.

Ce serait quand même pas mal d'apprendre les bases du langage avant de raconter tout un tas de conneries.

Le problème que j'essaie de montrer est compliqué à exprimer dans un forum et je conviens m'y être employé assez maladroitement. Néanmoins, je suis convaincu de la réalité du problème et je ne cherche qu'à vous en convaincre. Mon expérience en C++ est modeste mais je pense suffisante pour cela. N'oublie pas que tu as toujours le droit de ne pas t'intéresser à un post, ce qui est à mon avis plus utile que d'asséner ce genre d'affirmation méprisable et dommageable pour l'ambiance générale du forum.

[Patriarch24]

Si un constructeur lève une exception, alors il doit libérer lui-même les ressources qu'il a alloué, et la relancer dès que tout est propre. C'est aussi simple que cela.

http://www.parashift.com/c++-faq-lit....html#faq-17.2.

[dabeuliou]

Si un constructeur lève une exception, alors il doit libérer lui-même les ressources qu'il a alloué, et la relancer dès que tout est propre. C'est aussi simple que cela.

Certes, c'est même un simpliste ! Comment coderais-tu les constructeurs au sein d'une hiérarchie de 2 ou 3 classes en utilisant le mécanisme de try/catch spécifique aux constructeurs ? Genre C qui dérive de B qui dérive de A, avec des membres alloués dynamiquement dans A, B et C. Une exception étant susceptible d'être levée à chacun des trois niveaux, évidemment.

[Luc Hermitte]

try-catch ? Pourquoi faire ?
95% du temps le RAII me suffit. Si je garde un try-catch, c'est pour logger le problème tout en laissant l'exception remonter tranquillement.

Soit je ne vois pas le problème, soit quelqu'un est passé à côté du RAII.

[dabeuliou]

try-catch ? Pourquoi faire ?
95% du temps le RAII me suffit. Si je garde un try-catch, c'est pour logger le problème tout en laissant l'exception remonter tranquillement.

Sauf incompréhension de ma part, le RAII ne sera d'aucun secours dans le cadre d'une allocation dynamique de mémoire. Tu me diras peut-être qu'il faut alors utiliser une allocation sur la pile mais il y a des cas où l'allocation dynamique ne peut être évitée.
Bref, le try/catch est inévitable pour libérer des ressources allouées dynamiquement.

[Luc Hermitte]

Le RAII sert justement à encapculer les alloc dynamique. Le but étant qu'un objet ne soit pas directement resposable de plus d'une ressource brute.