Utilisation adéquate des exceptions

le second const signifie que l'on peut appeler la fonction même sur une instance constante de la classe ;)

les deux notations throw() et const en fin de signature pour une fonction membre peuvent être utiliser dans n'importe quelle classes...
et throw() peut même être utilisée sur n'importe quelle fonction (membre d'une classe ou non)

cependant, attention :
une fonction membre déclarée const NE DOIT PAS (et normalement ne peut pas : erreur à la compilation) modifier l'instance de la classe, ce qui est logique ;)

De plus, si jamais une fonction désigné comme sans exceptions avec throw() se retrouve à être traversée lors d'une levée d'exception (c'est-à-dire si jamais la fonction, ou une des fonctions qu'elle appelle étaient amenées à lever une exception), l'exception serait catchée et une exception std::bad_exception serait levée.

il me semble également qu'il existe une autre syntaxe pour throw() qui est de la forme :

Code:

---

RETOUR fonction(type1 var1, type2 var2, .....) throw(exception1, exception2, exception3, .......);

---

et qui précise les exceptions que PEUT lever une fonction... ici encore, si une exception non prévue est levée, elle sera remplacée par une std::bad_exception...

edit: j'avais pas vu le constructeur :)

pas implicitement, explicitement ;) il faut bien donner à l'exception la variable qui a provoquer l'erreur si on veut que l'exception nous y donne accès ;)

Salut Swoog, encore merci énormément pour la réponse.

Ca semble fonctionné, mon seul problème est que je ne peux pas vraiment utiliser _inst a des fins d'affichage (exemple je ne peux pas faire: return "conversion = echec dans la conversion de: " + ToConvert() car on se retrouve ici avec une conversion de l'élément en string alors si l'élément n'est pas convertible en string ca plantera.


Et en faisant:

Code:

---

if (!(iss >> integer)) throw ConversionFailure();

---

Si jamais il y aurait une exception, il afficherait le what() dans la console automatiquement?



Quelque chose qui me chicote aussi, afin d'améliorer la clarté du code j'essaie d'ajouter

Code:

---

static int ToInt(T) throw(ConversionFailure);

---

En utilisant la fonction comme suit:

Code:

---

1 2 3 4 5 6 7 8 9 10

template <class T> int Util::ToInt(T value) { std::istringstream iss(value); int integer; if (!(iss >> integer)) throw ConversionFailure();   return integer; }

---

à noter que pour le moment ma classe ConversionFailure est:

Code:

---

1 2 3 4 5 6

class ConversionFailure: public std::exception { public: virtual const char* what() const throw() { return "Erreur: echec dans la conversion."; } };

---

Mais il me dit

Citation:

---

62 E:\magic\VMM\unix_interface\util.h declaration of `static int Util::ToInt(T)' throws different exceptions

---

Citation:

---

Envoyé par loufoque

Regarde plutôt boost::lexical_cast

---

Je ne peux pas ;) (Je suis dans un labo de recherche et tout doit rester propriétaire, c'est pas moi qui décide!)

Alolrs, effectivement, tu ne peux pas afficher _inst de manière brute...

Cependant, tu es censé être capable de déterminer au moins le type de la variable que tu essaies de convertir dans ton code, au moment de l'appel de la fonction ConvertTo.
De ce fait, tu es tout à fait capable de déterminer le type de la variable renvoyée par ToConvert()
et donc de faire les traitements nécessaires pour afficher à l'écran (ou dans la console) et les informations te permettant d'identifier l'instance ;)

Il ne faut pas oublier un truc : toi, ce que tu te charges de faire avec l'exception, c'est signaler que l'appel à la fonction a généré une erreur.
Tu signale le type d'erreur (Conversion impossible) et tu peux en plus ajouter des informations supplémentaires (en l'occurence, la variable que tu tentais de convertir)

Tu n'as pas à t'occuper des traitements à faire pour palier à l'erreur, ou pour en identifier la cause, tu as juste à vérifier que tous les éléments nécessaires sont présents.

Dans ce cas, le try devra englober l'appel à la fonction, donc on saura forcément : le type de la variable que l'on veut convertir, le type que l'on désirait après conversion.
Toi, avec l'exception, tu ajoutes la variables que l'on voulait convertir.

Je ne pense pas qu'on puisse donner plus d'éléments pour identifier la cause de l'erreur.

Donc ça sera ensuite à celui qui utilisera ta fonction d'identifier la cause de l'erreur à partir des différents types et valeurs des variables ;)




Ensuite pour le catch qui affiche automatiquement le what : non ce n'est pas faisable ainsi,

cependant, tu peux tout à fait, en période de debug, utiliser une petite syntaxe :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

template <class T> int Util::ToInt(T value) { std::istringstream iss(value); int integer; if (!(iss >> integer)) { if(/*__DEBUG__*/) cerr <<"Impossible de Convertir" <<endl; throw ConversionFailure(); }   return integer; }

---

ceci te permettra d'afficher un message en cas d'erreur...
Sinon, un débuggueur pourrais être configuré pour s'arretter dès la levée d'une exception, et te permettre ainsi d'inspecter les variables et voir ce qui l'a provoquée.

encore une fois, tu n'as pas à t'occuper des erreurs générées par ta fonctions si elles sont prévues : Tu n'as pas à te soucier de ce qu'il va se passer si on te donne des données que tu ne peux pas traiter. Tu signales simplement que tu ne peux pas les traiter, ensuite c'est à celui qui te les a données de se débrouiller ;)


pour la dernière question : il te faut repréciser l'attribut throw() dans la définition de la fonction :

Code:

---

1 2 3 4 5 6 7 8 9

template <class T> int Util::ToInt(T value) throw(ConversionFailure) { std::istringstream iss(value); int integer; if (!(iss >> integer)) throw ConversionFailure();   return integer; }

---

pour plus de clarté, si une fonction utilise l'attribut throw() pour déclarer les exceptions qu'elle pourrait lever, je dirais qu'elle est exception-safe ;)

cependant prend garde :

• dans cette fonction, tu effectues une copie de T, qui est un type dont tu ne sais RIEN
• tu alloues deux variables : un std::istringstream et un int
• tu initialises le std::istringstream avec un T (dont encore une fois, tu ne sais rien !
• tu fais appelle a une fonction qui ne précise pas quelles exceptions elle pourrait lever (l'opérateur >> sur iss et integer), bien qu'en théorie elle ne doive pas le faire, tu n'en es pas sûr à 100% je ne crois pas qu'elle soit exception-safe
• tu retournes une variable par copie

donc ici, tu as 5 sources potentielles de levée d'exception :

• peut-être la copie de T est-elle impossible, et peut-être son constructeur de copie lévera une exception !
• peut-être la mémoire occupée par le programme est saturée, auquel cas la création de variable pourrait lever notamment une exception std::bad_alloc
• peut-être le constructeur de std::istringstream qui prend pour paramètre un T lèvera une exception, il ne me semble pas que les constructeurs de std::istringstream soient exception-safe
• peut-être l'opérateur >> exercer sur iss et integer lévera une exception
• peut-être l'allocation mémoire nécessaire pour la copie de la valeur de retour lévera une exception de type bad_alloc ou autre...

Comme tu le vois, il est très difficile de faire du code qui soit exception-safe (i.e. : qui puisse ciconscrire très précisément les exceptions qu'il pourrait lever) Je pense que c'est une des raisons qui font que throw() est très très rarement utilisé ;)

Citation:

---

Je ne peux pas ;) (Je suis dans un labo de recherche et tout doit rester propriétaire, c'est pas moi qui décide!)

---

Quel rapport ? Aucun.
Relis la licence de boost. Encore heureux qu'on peut mettre ça dans du logiciel propriétaire...

De toutes façons ce n'est rien de plus que ce qui a été dit avant mais en mieux.

Swoog: merci pour cette réponse, je l'étudierai plus en profondeur demain à mon retour au travail et te tiendrai au courant du dénouement!

loufoque: Je crois que tu m'as mal compris. Ce que je voulais dire est que le directeur des recherches souhaitent que tout ce qui est dans son logiciel aient été développé par l'équipe elle-même. Autrement dit, il ne veut pas utiliser des bibliothèques externes commes boost etc.. Je suis pas à 100% pour l'idée mais c'est pas moi qui décide.

Parce que vous avez développé votre propre implémentation de la bibliothèque standard aussi ?

Personnellement je ne suis pas favorable à une exception ConversionFailure. Une conversion qui échoue, ce n'est pas quelque chose d'exceptionnel. L'appelant est en droit de s'attendre à ce que sa conversion échoue, et il est le plus à même de traiter l'échec.
Je préfère avoir recours à un stupide booléen, à la Qt par exemple:

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 27

template <class T> int Util::ToInt(const T & value, bool * ok = 0) // référence tant qu'à faire { std::istringstream iss(value); int integer; bool res = (iss >> integer);   if ( ok ) { *ok = res; } else { assert( res ); // par exemple, plus utile et moins "pollueur" qu'un cerr }   return integer; }   std::string s = "10"; int a = Util::ToInt( s ); // sûr de soit bool ok; int b = Util::ToInt( s, &ok ); if ( !ok ) { // erreur }

---

y'a d'autres alternatives:

Code:

---

1 2 3 4 5 6 7 8 9

std::string s = "10"; int a; Util::ToInt( s, a ); // sûr de soit   int b; if ( !Util::ToInt( s, b ) ) { // erreur }

---

Salut Aurelien, merci pour cette alternative.

J'ai un peu de mal à comprendre parcontre le bout suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10

std::string s = "10"; int a; Util::ToInt( s, a ); // sûr de soit   int b; if ( !Util::ToInt( s, b ) ) { // erreur }

---

Comment se fait-il que la fonction puisse être évaluer comme booléenne? La fonction retourne la variable integer, alors si c'est 0 ce sera false mais si c'est n'importe quel autre valeur ce sera true...?

Merci :)


Swoog:

Dans le cas d'une levée d'exception, par exemple

Code:

---

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

class ConversionFailure: public std::exception { public: virtual const char* what() const throw() { return "Erreur: echec dans la conversion."; } };   template <class T> int Util::ToInt(const T & value) throw(ConversionFailure) { std::istringstream iss(value); int integer; if (!(iss >> integer)) throw ConversionFailure();   return integer; }

---

Qu'est-ce que le programmeur verrait lors de la levée de l'expression? le what() par défaut?




loufoque: La bibliothèque standard est dans le C++ Standard de base, boost est une bibliothèque additionnelle et il en veut pas. Qu'est-ce que tu veux que je te dise ? C'est pas moi qui décide? Comme je t'ai dit je n'approuve pas vraiment ce choix. Je peux te faire un dessin maintenant si tu ne comprends pas encore.

Citation:

---

Comment se fait-il que la fonction puisse être évaluer comme booléenne? La fonction retourne la variable integer, alors si c'est 0 ce sera false mais si c'est n'importe quel autre valeur ce sera true...?

---

Exactement, 0 correspond à false et... tout le reste correspond à true.

Citation:

---

Qu'est-ce que le programmeur verrait lors de la levée de l'expression? le what() par défaut?

---

Cela dépend comment tu récupére l'exception !

Code:

---

1 2 3 4

catch (const & Failure E) { cerr << E.what(); }

---

Dans ce cas il vera le contenue de what() de la classe failure

Aurelien.Regat-Barrel a modifié ainsi la fonction pour sa second portion de code :

Code:

---

1 2 3 4 5 6

template <class T> bool Util::ToInt(const T & value, int& result) { std::istringstream iss(value); return (iss >> result); }

---

;) d'où sa syntax... différente ^^

Ah voila, il me semblait aussi qu'il fallait que la fonction soit modifiée ahah :)


Mais je me trouverai donc forcemment avec un bloc try/catch chaque fois que je voudrais utiliser Util::ToInt? Sinon il aura une levé d'exception mais qu'est-ce qui lui dira quel genre d'exception il s'agit?

dans le cas proposé par Aurelien, la levé d'exception est remplacée par le renvoie d'un booléen ;)

Hum....... je suis en train de me demander si tout ceci en vaut vraiment la peine pour une conversion car comme Aurelien me l'a fait remarqué. Le programmeur a forcemment l'attente que la conversion peut échouer..

C'est pas possible d'utiliser directement Util::ToInt("21")
exemple:

Code:

---

todraw.insert(std::make_pair(Util::ToInt(nomaillage),childvalue));

---

Et si jamais y'a une exception BOOM ca lui balance. Enfin, je rêve p-e un peu? :oops: Je présume que c'est pas aussi facile :P

justement avec le système d'exception sur le quel on était au début, c'est ce qu'il se passait ;)

En gardant mon:

Code:

---

1 2 3 4 5 6

class ConversionFailure: public std::exception { public: virtual const char* what() const throw() { return "Erreur: echec dans la conversion."; } };

---

Code:

---

1 2 3 4 5 6 7 8 9 10

template <class T> int Util::ToInt(const T & value) throw(ConversionFailure) { std::istringstream iss(value); int integer; if (!(iss >> integer)) throw ConversionFailure();   return integer; }

---

?


Mais, lorsque l'exception est lancée que se passe-t-il exactement? (Je n'ai jamais travailler avec les exceptions en C++ donc je ne sais pas vraiment comment elles sont envoyées au programmeur).

Il aura un message dans le compilo qui contiendra le what() de l'exception?

les exceptions sont levées à l'exécution (toujours)

elles remonte la pile d'appel de fonction jusqu'à tomber dans un bloc try/catch qui les récupère et les traite...

si elles ne sont pas traitées et remontent jusqu'à sortir de la fonction main, le programme plante tout simplement (erreur fatale je crois)

c'est donc à celui qui appel la fonction de l'intégrer à un bloc try/catch s'il pense que la valeur de la variable qui est communiqué risque de faire échouer la conversion, et donc lever une exception...

Je vois, donc si je comprend bien:

Une utilisation avec des int,string ne serait pas pertinente d'être dans un bloc try catch puisque ce sont des types de base qui ne peuvent pratiquement pas échouer.

Cependant si le programmeur implémente plus tard d'autre conversion (avec mes fonctions Util:: ) avec des objets qu'il a créer il devra le mettre dans un bloc try catch, et comme j'aurai deja fait le traitement d'exception, si une exception a lieu il sera tenu au courant et il pourra faire cerr << e.what() pour savoir ce qui cloche?

Voilà, exactement :D