throw dans un prototype

Bonsoir,

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

Code:

---

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

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

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.

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 ?

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.

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).

C'est clair.

Merci à tous.

Citation:

---

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

---

J'adore cet article :mrgreen:

Citation:

---

Envoyé par Médinoc

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

---

Pour paroder, il faut pas arriver en premier; :P
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:

---

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.

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