M�canisme C++ d'exceptions dans les constructeurs => inutilisable ?

**dabeuliou** · 28/01/2007, 12h15

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** · 28/01/2007, 13h00

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** · 28/01/2007, 13h06

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** · 28/01/2007, 14h49

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** · 28/01/2007, 15h51

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** · 28/01/2007, 18h40

Envoy� par 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.

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

**JolyLoic** · 28/01/2007, 18h43

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

**dabeuliou** · 28/01/2007, 19h21

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** · 28/01/2007, 23h45

Envoy� par dabeuliou

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** · 29/01/2007, 15h57

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** · 29/01/2007, 18h04

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** · 27/02/2007, 14h16

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** · 27/02/2007, 15h02

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** · 27/02/2007, 16h05

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** · 27/02/2007, 18h23

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** · 27/02/2007, 22h28

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** · 27/02/2007, 23h07

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** · 28/02/2007, 08h33

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** · 28/02/2007, 10h23

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.

M�canisme C++ d'exceptions dans les constructeurs => inutilisable ?

C++

Discussions similaires

Partager

Partager