exception dans un constructeur

Salut,

Je programme en C++ et je suis actuellement confronté a la possibilité de lancer une exception dans un constructeur.

j'ai trouvé le liens suivant sur developpez.com :
http://www.developpez.com/c/megacours/x3910.html

seulement il y a quelque chose qui m'echappe, que retourne le new quand une exception est lancée ? un objet partiellement intialisé ?

Code:

---

1 2 3 4

// supposons que l'Exception a ete lancee est // traitee en interne comme expliquée sur le lien Objet* obj = new Objet();

---

que vaut obj ? est-il NULL ?

XXiemeciel

obj n'est pas cree. Il n'est meme pas accessible aux endroits ou tu peux
capturer l'exception.

Citation:

---

Envoyé par jmarc68

obj n'est pas cree. Il n'est meme pas accessible aux endroits ou tu peux
capturer l'exception.

---

donc obj est NULL ?

XXiemeciel

Non, obj n'est pas cree. Si tu lances une exception dans ton constructeur,
new ne retourne rien, la propagation de l'exception continue et la ligne
suivant ta definition n'est pas executee.

Citation:

---

Envoyé par jmarc68

Non, obj n'est pas cree. Si tu lances une exception dans ton constructeur,
new ne retourne rien, la propagation de l'exception continue et la ligne
suivant ta definition n'est pas executee.

---

donc il faudrait encapsuler dans un try/catch l'appel a new ?

Code:

---

1 2 3 4 5 6 7 8 9 10

Objet * obj = NULL;   try { obj = new Objet(); } catch(...) { }

---

j'espere que non car je ne peux pas reprendre les 8000 fichiers cpp de l'application pour rajouter un try/catch a chaque new.

XXiemeciel

Salut,

Tu peux aussi jeter un coup d'oeil à:
http://c.developpez.com/faq/cpp/?pag...S_constructeur
http://c.developpez.com/faq/cpp/?pag...POINTEURS_raii

:)

Je vais legerement detourner la question initiale :D

Est ce que en cas d'erreur de mon constructeur je peut faire quelquechose pour que new retourne NULL ?

le fait que l'exception se propage en dehors du constructeur me gene trop pour que je puisse l'utiliser.

XXiemeciel

Si tu quites ton constructeur par une exception, tu dois la recuperer quelque part, non? Si
ca ne te plais pas, plutot que de quiter le constructeur par une exception, tu peux avoir
un drapeau d'etat qui indique que ton objet n'est pas correctement initialise et le tester
(un peu comme ce qui se passe pour les stream).

Citation:

---

Envoyé par xxiemeciel

Est ce que en cas d'erreur de mon constructeur je peut faire quelquechose pour que new retourne NULL ?
l

---

Non. Pense au cas

Class obj(args...);

Il n'y a pas d'equivalent a NULL.

Merci de vos reponses,

Je pense que puisque je ne peux pas repasser a travers tout le code pour voir a quelles endroits mon objet est utilisé et changer chaque appel a new, je vais tout simplement prevoir un comportement de l'objet speciifique aux mauvaises utilisations.

XXiemeciel

Il existe une version de new qui ne lève pas d'exception : new(std::nothrow). Par contre je ne sais pas si elle renvoie NULL seulement à la place de std::bad_alloc, ou si elle attrape toute exception et la transforme en NULL.

Est ce que je pourrais redefinir new seulement pour mon objet ?

XXiemeciel

Citation:

---

Envoyé par Loulou24

Il existe une version de new qui ne lève pas d'exception : new(std::nothrow). Par contre je ne sais pas si elle renvoie NULL seulement à la place de std::bad_alloc, ou si elle attrape toute exception et la transforme en NULL.

---

C'est simplement une version de new qui le lance pas de std::bad_alloc.

Quelque chose comme

Code:

---

1 2 3

Foo* p = new Foo(); Bar* q = new(std::nothrow) Bar();

---

est compile comme

Code:

---

1 2 3 4 5

Foo* p = operator new(sizeof(Foo)); new(p) Foo(); Bar* p = operator new(std::nothrow, sizeof(Bar)); new(q) Bar();

---

L'exception lancee eventuellement par le constructeur a lieu alors que operator new a
deja retourne.

Citation:

---

Envoyé par xxiemeciel

Est ce que je pourrais redefinir new seulement pour mon objet ?

---

Non. Les possibilites de surcharge de new ne permettent pas ce genre de chose. Seulement
de changer ce qui concerne l'allocation memoire.

Bon dans ce cas je vais rester sur ma premiere idée et faire un comportement special de l'objet plutot que de lancer une exception.

Merci
XXiemeciel

Tu ne peux pas envelopper ta construction ?

Citation:

---

Envoyé par jmarc68

Citation:

---

Envoyé par xxiemeciel

Est ce que je pourrais redefinir new seulement pour mon objet ?

---

Non. Les possibilites de surcharge de new ne permettent pas ce genre de chose. Seulement
de changer ce qui concerne l'allocation memoire.

---

Je n'ai jamais testé de redéfinir new, mais le tout premier lien donné (http://www.developpez.com/c/megacours/x3910.html) donne ce bout de code:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class A { public: A() throw (int); ~A();   static void *operator new(size_t taille) { cout << "new()" << endl; return malloc(taille); }   static void operator delete(void *p) { cout << "delete" << endl; free(p); } };

---

Est-ce que ca redéfinit l'operateur new peu importe son contexte d'utilisation ? Et si oui, quel est l'intérêt de le mettre comme operateur statique de la classe A ?

Citation:

---

Envoyé par bigquick

Je n'ai jamais testé de redéfinir new, mais le tout premier lien donné (http://www.developpez.com/c/megacours/x3910.html) donne ce bout de code:

Code:

---

1 2	definition de new et de delete en tant que membres statiques

---

Est-ce que ca redéfinit l'operateur new peu importe son contexte d'utilisation ? Et si oui, quel est l'intérêt de le mettre comme operateur statique de la classe A ?

---

Definir un operateur new comme membre (il est alors d'office statique, que l'on l'indique comme tel ou non) fait qu'il est utilise pour allouer des instances de lla classe et ses descendants (mais pas pour allouer autre chose dans les membres de la classe et des descendants).

C'est donc une technique beaucoup moins brutale que de substituer l'operateur new global (qui alors s'impose a toutes les classes ne definissant pas d'operateur new membre). La definition d'un operateur new global devrait etre reserve a l'application et jamais impose par des bibliotheques.

Ici ce n'est pas new le problème, mais le constructeur de l'objet.
l'exception peut être est levée même sans new:

Code:

---

1 2 3 4 5 6 7 8 9

try { Object obj; // peut lever une exception } catch ( ... ) { // et là je fais quoi ? }

---

Si tu peux revoir la conception de la classe c'est peut être mieux que de bricoler new, ou alors créer un objet d'encapsulation ou une fonction de création comme le suggère Luc.

Allo,

Merci pour vos reponses, mais je fais du refactoring de code et cette objet est tres utilisé dans le code je ne peux pas me permettre de le changer completement ou de modifier les appels deja existant a cette objet, il y en a beaucoup trop.

Ca aurait été bien plus pratique pour moi que new retourne NULL dans le cas d'un echec du constructeur car tout les ancien appel au constructeur aurait continuer a fonctionner puique les pointeur sont testé systematiquement.

XXiemeciel

Code:

---

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

class Object { // ancien code   public: static Object* New() // renvoie NULL en cas d'échec { try { return new Object; } catch (... ) { return 0; } } };   // ...   Object *obj = Object::New(); if ( obj == NULL ) { // ... }

---

personnellement je désaprouve, mais c'est comme tu veux.

ce qui m'oblige encore une fois a changer tout les appels existant a new pour mon objet.

Donc retour a l'idée de depart , prevoir un comportement de l'objet dans le cas de l'Erreur.

XXiemeciel

J'ai compris que tu as la classe Object, qui est utilisée par beaucoup de code.
Toi, tu veux l'utiliser sans les exceptions.
Donc on te propose une solution où, sans toucher au code existant, tu peux rajouter une fonction que tu utilises comme tu le veux toi, et l'ancien code continue à être basé sur les exceptions.
Je ne comprends pas pourquoi tu veux modifier tous les appels à new.

Sinon, effectivement, si tu peux repenser à zéro ta gestion des erreurs et avoir un comportement cohérent, c'est mieux.
Une exception, normalement, tu la laisse filer parce que si elle est levée, l'appelant ne peux rien faire pour corriger cela.
Typiquement, il manque de la mémoire. Ah ben, tu obtiens un pointeur nul, et après tu fais quoi ? Tu renvoies à ton tour une erreur à l'appelant, qui lui ne sait pas quoi faire, et renvoie à son tour jusqu'à ce que quelque part un bout de code s'occupe de gérer le manque de mémoire... c'est exactement le principe des exceptions, sauf que c'est transparent.
Maintenant si dans un objet Fichier, c'est l'exception FileNotFound qui est levée quand on ouvre un fichier, ça devient trop lourd, puisque c'est typiquement l'appelant qui sait le mieux réagir à un échec d'ouverture du fichier.
Les exception, c'est juste un mécanisme de transport d'une information d'erreur. Il faut te poser la question du destinataire de chaque erreur. Si c'est l'appelant, l'exception sera un mauvais choix. Sinon elle peut être justifiée.

Le code sur lequelle je travail existe pour certaines partie depuis plus de 15 anset sont en C. Le systeme n'utilisait pas les exceptions meme pour le code C++ qui est venu apres.

Moi je suis chargé de tester certaines classe et de resoudre les problemes si j'en trouve. J'ai decouvert une faille dans un objet, si on lui passe un mauvais parametre de construction il se construit quand meme et a un mauvais comportement ce qui peut etre tres dangereux.

ma premiere idée a été de jeter une exception lorsque le parametre etait mauvais (la compagnie a rajouter un systeme d'exception il y a 2 mois seulement ...)

mais la je me suis rendu compte que jeter une exception dans un constructeur pouvait etre problematique, donc, comme je n'allais pas reprendre les 2 millions de ligne de code pour rajouter try/cacth a chaque appel de new sur mon objet j'ai essayé de trouver une autre solution.

Est-ce plus clair maintenant ?

XXiemeciel

Le problème est donc dans le choix des exceptions comme mécanisme de signalement d'erreur. Tu es en contradiction avec toi même:
- tu veux signaler une erreur avec une exception
- tu ne veux pas traiter cette erreur via les exceptions
tu peux alors maintenir un état "invalide" dans ton objet, comme le fait ifstream quand l'ouverture du fichier échoue:

Code:

---

1 2 3 4 5 6

std::ifstream fichier( "toto.txt" ); if ( !fichier ) // ou fonction type isValid() { // erreur }

---

si c'est bien l'appelant qui peut y faire quelque chose. Sinon, faut laisser filer l'exception. Mais note que dans les 2 cas, il faudra reprendre tout le code existant...
Note aussi que par défaut le test pour NULL sur le retour de new est toujours faux, sauf avec de vieux compilateurs (VC++ 6). Les compilateurs récent renvoient un objet créé, ou lèvent une exception, mais jamais NULL. C'est peut être un point qui peut justifier la reprise de tout votre code.

c'est pour cela que je dit que je ne vais PAS utiliser les exceptions et faire un comportement specifique au cas a probleme

XXiemeciel