Discussion :

[Bayard]

Bonsoir,

J'ai r�cup�r� le code suivant:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
void ma_classe::operator()( std::string data) const
throw( toto, titi )
{
  ....
}

Je sais ce c'est qu'un op�rateur.

Je sais ce qu'est que l'�mission d'une exception (throw())

Ce que je ne comprends pas c'est � quoi sert le throw AVANT l'accolade.

toto et titi sont des classes d�finies avant.

Merci

[hiko-seijuro]

cela veut dire tout b�tement que la m�thode qui va appeller cet op�ratur de va fair un try catch sur l'eception. En gros tu propages l'eception

[roulious]

C'est une sp�cification d'exception : cela signifie que les exceptions que la fonction devrait lancer sont de type toto et titi. Si la fonction lance une exception d'un autre type, cela conduit � un appel � la fonction int�gr�e unexpected, qui elle meme appelle la fonction d�finie par un set_unexpected, ou, si set_unexpected n'a pas �t� appel�, lance un std::bad_exception.

Le comportement de tout ce m�canisme est assez compliqu�, donc mieux vaut faire attention si tu l'utilises.

[Bayard]

hiko-seijuro -> Je n'ai pas compris. Les "eceptions" (peuch�re) n'ont pas � �tre propag�es. Elles se propagent toutes seules.
roulious -> c'est assez clair. Existe-t-il un tutoriel � ce propos ?

[roulious]

On trouve deux articles de Sutter sur le sujet, http://www.gotw.ca/gotw/082.htm et http://www.gotw.ca/publications/mill22.htm qui d�conseillent tous les deux l'utilisation.

Je ne me souviens pas avoir vu des articles conseillant leur utilisation, si quelqu'un a un lien �a m'int�resse.

[M�dinoc]

C'est une esp�ce de mauvaise parodie des d�clarations d'exceptions de Java.
En C++, �a ne sert � rien, puisque �a ne peut jamais garantir que la fonction ainsi d�clar�e ne lancera pas d'exception non-sp�cifi�e.
Tout ce que �a fait, c'est changer le type de plantage (on passe de exception � unexpected() et �a nous fait une belle jambe).

[Bayard]

C'est clair.

Merci � tous.

[M�dinoc]

go to terminate(), go directly to terminate(), do not pass catch, do not collect $200.

J'adore cet article

[Luc Hermitte]

C'est une esp�ce de mauvaise parodie des d�clarations d'exceptions de Java.

Pour paroder, il faut pas arriver en premier;
En fait, je ne suis pas s�r qu'il y ait beaucoup de bonnes justifications pour les utiliser. Quoique, j'ai crois� un document qualit� qui savait parfaitement comment cela fonctionnait et qui pourtant demandait � ce que l'on utilise ces fichues specifications d'exceptions.

Disons que si je devais m'en servir, ce serait de cette fa�on:

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
void f() 
#if defined(DEBUG)
throw( TotoException )
#endif
{
   try {
      code ...
   } 
   catch( TotoException const&) { throw ;}
   catch( std::exception const& e ) {
       throw TotoException(__FILE__, __LINE__, e.what());
   }
    catch( ... ) { // en fait, redondant avec la spec d'exception
       assert(! "Unexcepted exception in f()");
       throw TotoException(__FILE__, __LINE__, "Unexcepted exception in f()");
       // autant dire qu'en mode release, cela ne plante pas, mais on n'a pas 
       // la moindre idée de ce qui s'est passé => on n'est vraiment pas
       // avancés.
    }
 
}

Comme vous le voyez, c'est p�nible, pas tr�s propre. Et c'est pour ceux qui pr�f�rent les cores aux appels de terminate et autre unexpected. Sans compter que dans certaines fonctions, ce n'est pas tr�s grave, voire on pr�f�re ne pas transformer une exception. Tandis que dans d'autres fonctions, il est imp�ratif de tout intercepter -> fonctions d'interface.
Bref, non seulement je ne m'en sers pas, mais en plus, je les vire du code dont j'ai repris la maitenance.

[loufoque]

�a peut servir pour du code exp�rimental que ne doit jamais propager la moindre exception sous peine de comportement ind�fini.