Discussion :

[emmr.rida]

J'ai un ensembles de classes décrivant des exceptions qui peuvent être levées à chaque moment. Mon problèmes :

Code :

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

1
2
3
4
5
6
7
 
try {
    ...
    if(...) throw new DeriveeException(...);
    ...
} catch(BaseException *ex) {
}

Quand je throw une exception avec une classe dérivée de la class de base dans le bloque catch, ce dernier n'est pas appelé. En applicant, le bloque catch(...), les exception "throwées" sont interceptées mais sans les informations que je passe à travers les classes.
A ce stade du projet, je veux pas gaspiller du temps à coder plusieurs blocque catch un pour chaque type d'exception.

Y a-t-il une solution pour intercepter plusieurs exceptions en interceptant la classe de base comme dans le langage C#

Merci.

[hiura]

Oui : il s'agit d'utiliser les références ( const ) .

Pourquoi ça ne fonctionne pas avec les pointeurs ? Mon hypothèse c'est que T (const) * est trop différent de T alors que T (const) & est quasi similaire à T. Est-ce correcte ?

[Dreambeliever]

Ca marche avec les pointeurs!

Le code 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
#include <iostream>
 
using namespace std;
 
class A {};
class B : public A{};
 
int main()
{
    try
    {
        throw new B();
    }catch (A*)
    {
        cout << "..." << endl;
    } catch (B*)
    {
        cout << "!!!" << endl;
    }
    return 0;
}

me donne même un warning:

C:\Users\Dave\Documents\CODING\projets\dvp5\main.cpp||In function `int main()'
C:\Users\Dave\Documents\CODING\projets\dvp5\main.cpp|17|warning: exception of type `B*' will be caught|
C:\Users\Dave\Documents\CODING\projets\dvp5\main.cpp|14|warning: by earlier handler for `A*'|
||=== Build finished: 0 errors, 2 warnings ===|

[Davidbrcz]

ne jamais lancer d'exception en allouant dynamiquement un objet car new peut lancer des exceptions ce qui peut encore mettre plus le bazard.

Il faut allouer tes objets sur la pile et attraper les exceptions par références constante:

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
#include <iostream>
 
using namespace std;
 
class A {};
class B : public A{};
 
int main()
{
    try
    {
	B b;
        throw b;
    }catch (const A&)
    {
        cout << "..." << endl;
      } catch (const B&)
    {
        cout << "!!!" << endl;
    }
    return 0;
}

Comme B dérive de A, j'ai ici un warning de g++ car le second bloc ne sera jamais utilisé à cause de l'upcasting implicite de B en A et de la linéarité de l'évaluation des blocs "catch" (dès qu'un bloc convient, on ne regarde pas les autres, même si un meilleur existe pourtant après)

[Goten]

Ca marche avec les pointeurs!

Le code 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
#include <iostream>
 
using namespace std;
 
class A {};
class B : public A{};
 
int main()
{
    try
    {
        throw new B();
    }catch (A*)
    {
        cout << "..." << endl;
    } catch (B*)
    {
        cout << "!!!" << endl;
    }
    return 0;
}

me donne même un warning:

Ouai enfin, vla la misére pour gérer la mémoire après, c'est bon pour se taper des segfaults.. Bref comme la dit david c'est par référence constante qu'on attrape les exceptions.

[Dreambeliever]

Je n'ai jamais dit le contraire, je voulais bien faire remarquer que ça marche aussi avec les pointeurs. (d'ailleurs on peut utiliser des pointeurs sans faire d'allocation dynamique)

[koala01]

Salut,

Je n'ai jamais dit le contraire, je voulais bien faire remarquer que ça marche aussi avec les pointeurs. (d'ailleurs on peut utiliser des pointeurs sans faire d'allocation dynamique)

Ca, c'est beaucoup plus complexe à faire... et cela ne sert à rien

En gros Cela signifie que:

1. tu dois créer un objet du type de ton exception en dehors du bloc try
2. tu dois récupérer l'adresse de de cet objet dans le bloc try en vue de lancer l'exception OU
3. que tu passe l'exception par pointeur à la fonction qui risque de la lancer, ce qui implique [1] et [2] et n'apporte strictement rien

En d'autres termes: pourquoi faire simple quand on peut faire compliqué

(pour info, je remettrais plus facilement en cause le fait de récupérer l'exception sous une forme constante que celui de la lancer par valeur et de l'attraper par référence )

N'oublie pas que tout est fait en C++ pour essayer de t'éviter au maximum le recours aux pointeurs et à tout ce qu'ils peuvent sous-entendre (dont, principalement, l'allocation dynamique)...

Au final, l'utilisation même des pointeurs devrait se limiter aux cas où:

• il est nécessaire de créer dans un objet contenu une relation avec l'objet contenant
• il est nécessaire de créer un objet en relation avec un (ou des) objets de type identique (pile, file, liste, et tous ces genres de choses que la STL implémente de manière si efficace)
• il est nécessaire de créer une relation de contenant à contenu pour laquelle le contenu peut ne pas exister
• il est nécessaire de créer une relation de contenant à contenu pour laquelle la responsabilité de la durée de vie du contenu ne dépend pas du contenant

et l'utilisation de l'allocation dynamique devrait se limiter, à peu de choses près aux cas

• de la mise en oeuvre du polymoprhisme lorsque l'objet polymophe doit être renvoyé par la fonction
• lorsqu'un objet ne pouvant pas être copié doit survivre à la fonction qui le crée afin d'être renvoyé par cette fonction

En dehors de ces cas bien particuliers, l'utilisation de pointeurs et de l'allocation dynamique, surtout si ce n'est pas encadré par une politique d'utilisation de pointeurs intelligents, reviendra souvent à courir le risque de te tirer une balle dans le pied un jour ou l'autre...

Maintenant, ne me fait pas dire ce que je n'ai pas dit:

J'estime, à contrario de ce que pourrait laisser croire ce que j'ai écrit plus haut, qu'il est important de maitriser les phénomènes propres aux pointeurs et à l'allocation dynamique...

Simplement, il faut avouer que, même si le programmeur est chevronné, il souffre de son humanité, qui le rend, par nature, susceptible de commettre une erreur.

Personne n'est donc à l'abri du fait de provoquer, souvent par inattention, un phénomène de fuite de mémoire ou de double libération de la mémoire aux conséquences pouvant être catastrophiques, lorsqu'il s'agit de recourir aux pointeurs et à l'allocation dynamique de la mémoire.

C'est pourquoi le meilleur conseil à donner est d'envisager de n'y recourir que lorsque l'on n'a vraiment pas d'autres solutions et de ne le faire en veillant à apporter un soin et une attention toute particulière à ce que l'on fait

[Dreambeliever]

Salut,

Ca, c'est beaucoup plus complexe à faire... et cela ne sert à rien

En gros Cela signifie que:

1. tu dois créer un objet du type de ton exception en dehors du bloc try
2. tu dois récupérer l'adresse de de cet objet dans le bloc try en vue de lancer l'exception OU
3. que tu passe l'exception par pointeur à la fonction qui risque de la lancer, ce qui implique [1] et [2] et n'apporte strictement rien

En d'autres termes: pourquoi faire simple quand on peut faire compliqué

(pour info, je remettrais plus facilement en cause le fait de récupérer l'exception sous une forme constante que celui de la lancer par valeur et de l'attraper par référence )

N'oublie pas que tout est fait en C++ pour essayer de t'éviter au maximum le recours aux pointeurs et à tout ce qu'ils peuvent sous-entendre (dont, principalement, l'allocation dynamique)...

Au final, l'utilisation même des pointeurs devrait se limiter aux cas où:

• il est nécessaire de créer dans un objet contenu une relation avec l'objet contenant
• il est nécessaire de créer un objet en relation avec un (ou des) objets de type identique (pile, file, liste, et tous ces genres de choses que la STL implémente de manière si efficace)
• il est nécessaire de créer une relation de contenant à contenu pour laquelle le contenu peut ne pas exister
• il est nécessaire de créer une relation de contenant à contenu pour laquelle la responsabilité de la durée de vie du contenu ne dépend pas du contenant

et l'utilisation de l'allocation dynamique devrait se limiter, à peu de choses près aux cas

• de la mise en oeuvre du polymoprhisme lorsque l'objet polymophe doit être renvoyé par la fonction
• lorsqu'un objet ne pouvant pas être copié doit survivre à la fonction qui le crée afin d'être renvoyé par cette fonction

En dehors de ces cas bien particuliers, l'utilisation de pointeurs et de l'allocation dynamique, surtout si ce n'est pas encadré par une politique d'utilisation de pointeurs intelligents, reviendra souvent à courir le risque de te tirer une balle dans le pied un jour ou l'autre...

Maintenant, ne me fait pas dire ce que je n'ai pas dit:

J'estime, à contrario de ce que pourrait laisser croire ce que j'ai écrit plus haut, qu'il est important de maitriser les phénomènes propres aux pointeurs et à l'allocation dynamique...

Simplement, il faut avouer que, même si le programmeur est chevronné, il souffre de son humanité, qui le rend, par nature, susceptible de commettre une erreur.

Personne n'est donc à l'abri du fait de provoquer, souvent par inattention, un phénomène de fuite de mémoire ou de double libération de la mémoire aux conséquences pouvant être catastrophiques, lorsqu'il s'agit de recourir aux pointeurs et à l'allocation dynamique de la mémoire.

C'est pourquoi le meilleur conseil à donner est d'envisager de n'y recourir que lorsque l'on n'a vraiment pas d'autres solutions et de ne le faire en veillant à apporter un soin et une attention toute particulière à ce que l'on fait

Je n'ai jamais dit le contraire

Je suis d'accord que le plus simple c'est les références constantes et qu'il n'y a pas de raison de préférer autre chose.

Mais plus haut il était dit que ça ne marchait pas avec des pointeurs, ce qui est faux.

[emmr.rida]

En passant un objet par référence le destructeur de la class est appelée entre throw et catch et je perds les informations contenus par l'objet paramètre de catch.

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
 
#include <stdio.h>
 
class foo
{
public:
	char *buffer;
 
	foo(void)
	{
		buffer = new char[25];
		sprintf(buffer, "Suis-je toujours là?!");
	}
 
	~foo(void)
	{
		delete[] buffer; // J'y suis plus!
	}
};
 
void main(void)
{
	try {
		foo f;
		throw f;
	} catch(foo &f) {
		printf(f.buffer); // buffer est libéré automatiquement.
	}
}

[koala01]

En passant un objet par référence le destructeur de la class est appelée entre throw et catch et je perds les informations contenus par l'objet paramètre de catch.

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
 
#include <stdio.h>
 
class foo
{
public:
	char *buffer;
 
	foo(void)
	{
		buffer = new char[25];
		sprintf(buffer, "Suis-je toujours là?!");
	}
 
	~foo(void)
	{
		delete[] buffer; // J'y suis plus!
	}
};
 
void main(void)
{
	try {
		foo f;
		throw f;
	} catch(foo &f) {
		printf(f.buffer); // buffer est libéré automatiquement.
	}
}

Absolument pas, étant donné que, lorsque tu transmet une classe par référence constante, s'il n'existe pas d'objet, un objet temporaire est construit en utilisant le constructeur par défaut...

En plus, l'exemple que tu donne est l'exemple type de ce qu'il ne faut pas faire, et ce pour une série de raisons

[emmr.rida]

Oui, c'est vrai mais les données allouées dynamiquement à partir des paramètres que je fournie lors du throw sont perdu. Dans l'exemple que j'ai fournis dans mon dernier post, le buffer allouée dans le constructeur n'est pas récupéré par l'objet paramètre de catch.

PS : Le problème principal de cette discussion est résolu et ainsi sera la discussion. Je sais pas ce que je faisais de travaers!
Merci pour vos réponses.

Que la discussion continue...

[Jean-Marc.Bourguet]

Un objet jeté est toujours copié. La différence entre le catch par valeur ou par référence est de savoir s'il est copié une deuxième fois.

[Davidbrcz]

Dans ce cas, est ce qu'on pourait imaginer le cas suivant :
1) une exeception est lancé à cause du manque de mémoire
2) elle est copié, il n'y a vraiment plus de mémoire
3) goto 1)

Ou c'est du domaine de la SF de l'informatique ?

[Jean-Marc.Bourguet]

Tu peux te retrouver dans la situation où la copie n'est pas possible parce que l'exception est trop grosse (la copie se fait habituellement vers une zone réservée statiquement, certaines implémentations peuvent agrandir cette zone dynamiquement si besoin est). Je ne me souviens pas avoir jamais su ce qui devait se passer (std::terminate() me semble être un bon candidat, mais j'ai pas le temps de vérifier).

[emmr.rida]

Oui, c'est vrai mais les données allouées dynamiquement à partir des paramètres que je fournie lors du throw sont perdu. Dans l'exemple que j'ai fournis dans mon dernier post, le buffer allouée dans le constructeur n'est pas récupéré par l'objet paramètre de catch.

La classe de l'objet jeté par throw n'implémente pas un constructeur de copie. En y ajoutant un, le throw d'objet par référence passe comme il faut.

Encore merci pour vos réponses. Je dois maintenant modifier les throw pour jeter les objets par référence et non par allocation dynamique.

[Médinoc]

La formule classique pour la règle est "throw by value, catch by reference" (même si je préciserais "const reference").
Si la bibliothèque MFC de Microsoft ne respecte pas cette règle, c'est qu'elle a été faite avant que la règle soit complètement standardisée.

Quant à Java et .Net, c'est la philosophie opposée, donc ne pas s'en inspirer pour C++...