Discussion :

[sinasquax]

Bonjour a tous, j'ai un petit probleme avec ma conception des exceptions.

J'ai une classe CException avec un constructeur paramétré :

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
 
 
 class CException : public std::exception
 {
  public :
 
   CException () throw() {};
   CException (const std::string &msg) throw() { m_what = msg; };
 
   virtual const char *what (void) const throw() { return m_what.c_str(); };
 
  protected :
 
   std::string m_what;
 
 };

J'ai ensuite une hiérarchie de classe dérivée de CException en fonction de l'exception relevée :

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
 
 
 class CExceptionMemory : public CException
 {
 };
 
 class CExceptionMemoryAllocFailed : public CExceptionMemory
 {
 };
 
 class CExceptionFile : public CException
 {
 };
 
 class CExceptionFileOpen : public CExceptionFile
 {
 };
 
...

Le probleme est que si je veux lever une exception CExceptionFileOpen par exemple avec comme parametre le nom du fichier :

Code :

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

1
2
3
 
 
throw CExceptionFileOpen(filename);

Le compilateur me dit que CExceptionFileOpen n'a pas de constructeur avec un const std::string &, pourtant la classe de base (CException) contient ce type de constructeur.

Je peux corriger ce probleme en implémentant le constructeur paramétré dans chaque classe dérivée mais y a t'il une meilleure solution 'orienté objet' ?

D'après mes recherches, il n'y a pas d'autres solutions mais peut etre que je n'ai pas trouvé.

Merci

[koala01]

Salut, et bienvenue sur le forum.

Tu pourrais déjà envisager de choisir une autre classe d'exception (elles ne manquent pas dans la STL) que la classe std::exception comme base de... ta propre exception de base.

En effet, toutes les classes qui dérivent de std::exception disposent d'un constructeur prenant une référence sur une chaine de caractères constante, et fournissent le comportement adéquat pour what.

Ainsi, étant donné que tes exceptions personnalisées vont sensiblement toutes arriver en période d'exécution, et qu'une fois que tu auras mis ton programme au point, tu devrais à tout le moins avoir tester ta logique jusque dans les moindre recoins, tu pourrais décider de faire dériver ta classe CException de la classe ...runtime_error de manière à ce qu'elle "réalise" cette exception fournie par le langage .

Ce n'est qu'un détail en soi, mais, à partir du moment où cela te permet de te simplifier la tâche, pourquoi t'en passer

Ceci dit, ce n'est pas parce qu'une classe dont tu fais dériver une autre classe dispose d'un constructeur donné que la classe héritière accepte automatiquement un constructeur qui prend les même arguments.

Pire encore: Si tu déclare un seul constructeur dans ta classe de base, et que tu indique pour celui-ci des arguments n'ayant pas de valeur par défaut, tu sera de toutes manières obligé d'appeler le constructeur en lui fournissant tous les arguments non facultatifs.

Ainsi, si tu as une classe de base sous la forme de

Code :

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

1
2
3
4
5
6
7
 
class Base
{
    public:
        Base(const std::string& str);
        /* les autres méthodes et membres de la classe
};

et que tu as une classe dérivée dont le constructeur n'a pas besoin d'argument, donnant quelque chose ressemblant à
class Derivee : public Base
{
public:
Derivee(){}
};
(ou que tu laisse le compilateur mettre ses constructeurs par défaut)
tu te fera jeter par le compilateur parce que tu n'invoque pas explicitement le seul constructeur qui soit connu pour la classe de base (hormis le constructeur de copie).
L'implémentation du constructeur de la classe Derivee devrait au minimum ressembler à

Code :

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

1
2
3
Derivee::Derivee():Base("une chaine de caractères propre a la classe Derivee")
{
}

en outre, le constructeur qui prend (dans le cas présent) une chaine de caractères s'applique... à la classe de base et non à la classe dérivée.

Ainsi, le seul constructeur de Derivee que le compilateur connait est... le constructeur ne prenant pas d'argument

Et c'est la raison pour laquelle il te "jette" quand tu essaye de faire créer une instance (ici d'une exception particulière) de la classe dérivée.

Pour résoudre le problème, c'est tout simple:

Déclare un constructeur dans ta classe dérivée qui prend lui aussi une référence constante sur une chaine de caractères, sous la forme de

Code :

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

1
2
3
4
5
6
class Derivee : public Base
{
    public:
        Base(const std::string& str):Base(str){}
        /* les autres méthodes et membres de la classe */
};

ou, étant donné que le constructeur de ta classe de base prévoit une liste d'exceptions potentielles vide, il faudra prévoir un constructeur prenant la forme de

Code :

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

1
2
3
4
5
class Derivee : public Base
{
    public:
        Derivee(const std::string& str)throw():Base(str){}
};

[loufoque]

Les constructeurs ne sont pas hérités, il faut forwarder.
Il est néanmoins possible en C++0x de les hériter avec "using".

[Emmanuel Deloget]

y a t'il une meilleure solution 'orienté objet'

Euh, oui. La solution de base, qui précise qu'un lorsqu'un objet est crée et paramétré, son constructeur est appelé. Donc idem que les autres pour la réponse. (il ne faudrait pas confondre "je n'ai pas envie d'écrire du code" avec "c'est pas très objet tout ça". Le simple fait de redéfinir des classes d'exception qui existe déjà n'est pas très objet... )

Pour information, il est plus que formellement déconseillé d'utiliser un std::string pour stocker le texte associé à une exception. En effet, tout constructeur (et notamment ceux qui alloue de la mémoire) peuvent générer une exception. m_what = msg; peut générer une exception, malgré le throw() que tu as mis (et qui est, de fait, faux). Ce sera notamment le cas lorsque tu aura à gérer une exceptino de type std::out_of_memory. Hors, générer une exception lorsque tu es en train de générer une exception est une fort mauvaise idée. De fait, il est préférable d'éviter ce cas malheureux et de stocker le what sous la forme d'un char* ou wchar_t* (comme c'est fait dans std::exception, soit dit en passant).

[Médinoc]

Sous Visual, std::exception possède deux constructeurs acceptant un const char*, dont l'un qui est garanti ne pas tenter d'allouer de la mémoire.

Malheureusement, je ne sais pas ce qu'en dit la norme, et ni cppreference.com ni cplusplus.com ne documentent la classe exception...

[koala01]

D'après le standard, toutes les exceptions - hormis std::exception - utilisent une référence constante sur une chaine de caractères dans leur constructeur.

Il y a cependant une pré condition sous la forme de

Code :

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

strcmp(what(), what_arg.c_str()) == 0

[Emmanuel Deloget]

D'après le standard, toutes les exceptions - hormis std::exception - utilisent une référence constante sur une chaine de caractères dans leur constructeur.

Il y a cependant une pré condition sous la forme de

Code :

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

strcmp(what(), what_arg.c_str()) == 0

Ce qui a provoqué une discussion douloureuse à divers meetings du comité - cf Standard Library Defect Report List, 254: Exception types in clause 19 are constructed from std::string. Le fait est qu'avoir un constructeur d'exception qui génère une exception autre est dangereux au possible. Certes, il pourrait être agréable d'avoir un constructeur qui prenne un std::string& en paramètre.

Notez que dans 99,999% des cas, on s'en moque royalement - il est rare qu'on exploite la totalités de la mémoire d'un système, surtout si celui-ci gère une mémoire virtuelle qui peut s'étendre sur plusieurs GB. Mais dans le principe, il est quand même plus heureux d'éviter les std::string& dans ce cas (c'est bien le seul...)

[koala01]

Ah, je n'ai jamais dit que les décisions du comité étaient irrévocables ou non soumises à discussion...

J'ai juste indiqué que, dans la section 19.1 qui est relative aux exceptions, la norme indique en toutes lettres que leurs constructeurs prennent tous une référence constante sur une chaine de caractères comme paramètres, hormis la classe exception

N'étant pas dans les petits papiers du comité, je ne m'avancerai pas à faire la moindre supputation sur les discussions que leurs décisions ont pu entraîner, même si je reconnais qu'il y a un risque potentiel à ce point de vue

[Luc Hermitte]

Dans l'absolu, tout ceci est vrai.
Dans la pratique ... si on n'est pas capables d'allouer quelques malheureux 200 octets pour un message texte, qui seront à leur tour récupérés pour ouvrir une pop-up (ou balancer un exception corba, ou ...) ... comment dire?
J'ai comme l'impression qu'il y a au fond un problème bien plus grave, et que de toutes façons, il va falloir tout arrêter.

La probabilité que nous soyons dans l'appel d'une routine qui a consommé toute la mémoire sauf les 199 derniers octets du free store (et que sortir de la routine va nous restituer assez pour une pop-up, une excepton Corba, ...) me parait assez faible.

Dans le passé, j'avais des états d'âmes puristes vis à vis de ce problème, aujourd'hui c'en est un que je néglige allègrement.

[sinasquax]

Merci pour vos réponses, je vais donc écrire les constructeurs des classes dérivées.

Je crée mes exceptions a la place d'utiliser ceux de la std car j'aurai besoin d'exceptions spécifiques dans mon programme.

Merci aussi pour la note concernant le fait d'utiliser un const char * a la place d'un string pour éviter d'autres exceptions meme si c'est vrai que si l'allocation d'un string échoue alors il ne reste plus grand chose a faire.