la chaine de caractères dans std::exception

la chaine de caractères dans std::exception - C++ - Programmation

Marsh Posté le 08-09-2003 à 21:42:10    

bonjour,  
 
j'aimerais pouvoir utiliser la chaine de caractères que peut contenir std::exception.
 
j'ai vu qu'un de ses constructeurs est exception(const char* const & ) et qu'un de ses membres publics est const char * what(), mais je ne comprends pas qui doit allouer et désallouer la chaine, ou s'il y aurait plus simplement moyen d'utiliser std::string ?
 
un petit exemple svp :)
 
(j'ai essayé de regarder la définition de std::exception dans les header, j'ai rien compris ...)


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 08-09-2003 à 21:42:10   

Reply

Marsh Posté le 08-09-2003 à 21:50:08    

il peut y avoir une contre indication à l'utilisation des string, mais bon, c'est préférable de les utiliser et on ne va pas tatillonner  
 
 
const char * what() const
{
  return this->msg.c_str();
}


Message édité par Taz le 08-09-2003 à 21:50:36
Reply

Marsh Posté le 08-09-2003 à 21:57:33    

je peux donc faire :
 

Code :
  1. using namespace std;
  3. try
  4. {
  5. throw exception(string("message" ));
  6. }
  7. catch (const exception & e)
  8. {
  9. string s(e.what());
  10. }


?
 
elle est détruite quand l'exception ? (l'instance de std::exception)


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 08-09-2003 à 21:59:13    

j'ai aussi vu que std::exception avait un constructeur de copie, et un operator= est-ce obligatoire pour une classe d'exception ?


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 08-09-2003 à 22:00:51    

try
  {
    throw my_exception("message" );
  }
  catch (const exception & e)
  {
 
   // ici tu recontruit une string
    string s(e.what());
 
// vu la signature tu peux te contenter de
   
    const char*msg=e.what();
  }  
 
 
 
pas de problèmes d'allocation, si tu veux manipueler par contre, passe par une std::string effectivement
 
 

Reply

Marsh Posté le 08-09-2003 à 22:04:44    

throw exception(string("message" )); ne fonctionnait pas en effet.
Merci  :jap:


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 08-09-2003 à 22:42:28    

encore une tite question qui dévie un peu du sujet :
 
si un constructeur fait un exception, et qu'elle est gérée, est ce que le destructeur sera appelé ?


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 08-09-2003 à 22:44:45    

oula c'est une histoire compliquée tout ça, une très longue histoire. je crois que tu ferais bien de t'orienter vers le Stroustrup à ce niveau là (j'ai pas vocation à taper des pages du moins pas ce soir)

Reply

Marsh Posté le 08-09-2003 à 22:52:01    

laisse moi la soirée pour t'en parler

Reply

Marsh Posté le 08-09-2003 à 23:05:22    

:)  :jap:


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 08-09-2003 à 23:05:22   

Reply

Marsh Posté le 08-09-2003 à 23:23:51    

la réponse est non. l'objet n'étant pas construit, il pourrait etre désastreux d'exécuter le destructeur. par contre, les membres correctment initialisés sont détruits. l'initialisation est une bonne méthode pour avoir un comportement sain d'ailleurs
 
note le bloc try-catch fonctionnel autour du destructeur qui peu t'aider à gérer les exceptions lancées à l'initialisation des membres.
 
le problème qui apparait, c'est en cas d'allocation dynamique, il n'y a aucun moyen de libérer la mémoire en cas d'exception. que se passe t'il en effet si au cours du constructeur, quleque chose jète une exception? comment faire pour savoir quoi et quand se qui s'est passé?  le bloc try-catch fonctionnel peut t'aider, mais uniquement dans certains cas, et fastidieusement. bref, fuite de mémoire. la solution sure est donc d'encapsuler systématiquement les allocations dans des porteurs. d'ou le role tres fort des conteneurs STL qui apportent beaucoup de sécurité. c'est bon ?
 
 

Code :
  1. #include <iostream>
  2. #include <stdexcept>
  4. using namespace std;
  8. class Foo
  9. {
  10.  
  11. public:
  12.  
  13.   Foo(bool throwEx = false)
  14.   {
  15.     if(throwEx)
  16.       {
  17. throw invalid_argument("Erreur Foo" );
  18.       }
  20.     cout << "Foo()\n";
  21.   }
  23.   ~Foo()
  24.   {
  25.     cout << "~Foo()\n";
  26.   }
  27. };
  30. class Bar
  31. {
  32.   Foo f;
  34. public:
  35.  
  36.   Bar(bool throwEx)
  37.     : f(false)
  38.   {
  39.     Foo(true);
  40.     cout << "Bar()\n";
  41.   }
  43.   ~Bar()
  44.   {
  45.     cout << "~Bar()\n";
  46.   }
  47. };
  50. class Bar2
  51. {
  52.   Foo f;
  53.   Foo g;
  54.   Foo h;
  56. public:
  57.  
  58.   Bar2(bool throwEx)
  59.     : f(false), g(throwEx), h(false)
  60.   {
  61.     cout << "Bar2()\n";
  62.   }
  64.   ~Bar2()
  65.   {
  66.     cout << "~Bar2()\n";
  67.   }
  68. };
  72. class Bar3
  73. {
  74.   Foo f;
  75.   Foo g;
  76.   Foo h;
  78. public:
  79.  
  80.   Bar3(bool throwEx)
  81.     try
  82.     : f(false), g(throwEx), h(false)
  83.   {
  84.     cout << "Bar3()\n";
  85.   }
  86.   catch(const std::exception &ex)
  87.   {
  88.     cerr << "***" << ex.what() << endl;
  89.   }
  91.   ~Bar3()
  92.   {
  93.     cout << "~Bar3()\n";
  94.   }
  95. };
  98. int main()
  99. {
  100.   try
  101.     {
  102.       Foo(true);
  103.     }
  104.   catch(const std::exception &ex)
  105.     {
  106.       cerr << ex.what() << endl;
  107.     }
  109.   cout << "\n";
  112.   try
  113.     {
  114.       Bar(true);
  115.     }
  116.   catch(const std::exception &ex)
  117.     {
  118.       cerr << ex.what() << endl;
  119.     }
  121.   cout << "\n";
  124.   try
  125.     {
  126.       Bar2(true);
  127.     }
  128.   catch(const std::exception &ex)
  129.     {
  130.       cerr << ex.what() << endl;
  131.     }
  133.   cout << "\n";
  136.   try
  137.     {
  138.       Bar3(true);
  139.     }
  140.   catch(const std::exception &ex)
  141.     {
  142.       cerr << ex.what() << endl;
  143.     }
  144. }

Reply

Marsh Posté le 08-09-2003 à 23:39:17    

note aussi le fonctionnement de Bar.  
sinon je réinsiste sur la technique « acquisition par initialisation » et te conseille quand tu le peux pas l'utilisation de pointeurs intelligents (à commencer par les std::auto_ptr) qui te garantiront de ne pas laisser de fuite de mémoire en cas d'exception.

Reply

Marsh Posté le 08-09-2003 à 23:49:54    

j'etudie tout ca, merci  :jap:


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 09-09-2003 à 15:13:22    

mon compilo (vc++7) me renvoit :
 
Erreur Foo
 
Foo()
~Foo()
Erreur Foo
 
Foo()
~Foo()
Erreur Foo
 
Foo()
~Foo()
***Erreur Foo
~Bar3()
~Foo()
~Foo()
~Foo()
 
je comprends pas trop d'ou viennent les 3 derniers ~Foo()...
 
pour le reste, d'apres ce que j'ai compris les objets construits avant l'exception sont détruits, ceux qui étaient en train de se construire (l'exception est remontée a travers leurs constructeurs) sont laissés en plan et pas détruit, et evidemment ceux qui auraient du être construit apres l'exception ne le sont pas.


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 09-09-2003 à 19:15:07    

moi j'ai ça
 
 
Erreur Foo
 
Foo()
~Foo()
Erreur Foo
 
Foo()
~Foo()
Erreur Foo
 
Foo()
~Foo()
***Erreur Foo
Erreur Foo
 
 
c'est un problème parce que gcc fait une optimisation de base suggérer par la norme. fais un constructeur de copie avec un affichage et tu verras

Reply

Marsh Posté le 09-09-2003 à 19:33:40    

Citation :

encapsuler systématiquement les allocations dans des porteurs


 
c'est du chinois pour moi, qq1 peut m'expliquer ?
sinon j'essaie de me plonger dans la doc de la stl, mais ce n'est malheureusement pas à ma portée encore visiblement...


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 09-09-2003 à 19:34:25    

merci Taz  :jap:  j'ai bien compris le principe des exceptions dans les constructeurs :)


---------------
-( BlackGoddess )-
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed