Exceptions en C++0x

**minnesota** · 09/06/2010, 00h57

[Déplacé depuis http://www.developpez.net/forums/d91...e-chez-google/]

Bonjour,

Je ne sais pas si ça a déjà été évoqué, mais j'ai vu dans votre discussion beaucoup de critiques envers Google tenant au fait que leur règle de codage interdit l'usage des exceptions. Mais ces dernières ne sont-elles pas dépréciées dans la nouvelle norme ? Même si leurs règles sont antérieures à la nouvelle norme, je suis certain que ça n'a rien à voir avec la clairvoyance, enfin si je ne me trompe pas pour l'histoire de la dépréciation.

gl · 09/06/2010, 01h16

Envoyé par minnesota

Mais ces dernières ne sont-elles pas dépréciées dans la nouvelle norme ? Même si leurs règles sont antérieures à la nouvelle norme, je suis certain que ça n'a rien à voir avec la clairvoyance, enfin si je ne me trompe pas pour l'histoire de la dépréciation.

Non, il n'est pas question de dépréciée les exceptions dans la future norme.

Ce qui sera déprécié, ce sont les spécifications d'exception (qui ne me semble pas avoir été vraiment utilisé en pratique à l'exception de "throw nothing").

**minnesota** · 09/06/2010, 01h27

Merci pour ta réponse.

Donc, il y aura toujours des exceptions, mais sous une autre forme que jusqu'à maintenant.

Où pourrais-je me procurer un max de détails sur la question autre que les comptes rendus des sempiternelles réunions du comité de standardisation du C++ ?

Merci.

<edit>Est-ce que ça vaut la peine d'ouvrir une discussion sur ce sujet ?</edit>

**Luc Hermitte** · 09/06/2010, 03h21

Non, rien ne change pour le commun des mortels qui s'y prenait bien. Ce sont les spécification d'exception (qui parasitent les signatures des fonctions) qui sont dépréciées.

**koala01** · 09/06/2010, 03h25

Envoyé par minnesota

Merci pour ta réponse.

Donc, il y aura toujours des exceptions, mais sous une autre forme que jusqu'à maintenant.

Non, les exceptions resteront telles qu'elles sont...

Ce qui est déprécié, c'est la partie qui concerne la spécification des exceptions qu'une fonction risque de lancer (dont une des formes les plus souvent rencontrées et le "notrow"):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Type foo() throw(std::bad_alloc){}
const char * exception::what()throw(){}

L'idée de base de cette approche est d'interdire à foo de lancer une autre exception que bad_alloc (selon l'exemple).

Le fait est que, bien souvent, si tu décide de placer une telle spécification, c'est que tu envisage de faire un new ou un new[] qui cours le risque d'échouer.

Seulement, il arrive souvent que, dans cette fonction, tu fasse appel à... d'autres fonctions, et que ces fonctions puissent elles-même faire appel à d'autres...

Au bout d'un moment, il devient donc difficile de s'assurer qu'aucune des fonctions appelées ainsi "en cascade" ne lancera une autre exception qu'une... std::bad_alloc.

Or, si l'exception n'est pas rattrapée, elle peut parfaitement remonter jusqu'à... foo.

Le résultat est alors sans appel: comme foo ne peut "sortir" (sur exception) que suite à... une std::bad_alloc, le programme se trouve face à une exception inattendue et la seule chose qu'il puisse faire dans ce cas est, simplement de s'arrêter brutalement, en perdant, au passage, toutes les informations qui auraient pu être véhiculées par l'exception qui aura occasionné ce massacre

C'est pourquoi la nouvelle norme considère qu'il n'est opportun de laisser qu'une alternative:

soit une fonction est susceptible d'être quittée sur n'importe quel type d'exception (c'est la règle générale)
Soit la fonction ne peut pas être quittée suite à une exception (c'est... l'exception qui confirme la règle, en gros )

Mais comme, traditionnellement, une paire de parenthèse est associée à une liste d'informations séparées par une virgule, il me semble que la norme C++11 préfère maintenant un terme clairement explicite comme no_throw pour qualifier une fonction qui ne doit en aucun cas s'arrêter suite à une exceptions non gérée.

Où pourrais-je me procurer un max de détails sur la question autre que les comptes rendus des sempiternelles réunions du comité de standardisation du C++ ?

Dans cette discussion, tu dispose de liens vers certains draft de la prochaine norme.

Il faut juste préciser, sur le sujet:
Le draft présenté a été voté, mais doit encore passer une étape de commentaires. Il a donc de bonnes chances de préfigurer la prochiane norme, mais, s'il y a (beaucoup de) des commentaires importants, il risque malgré tout d'évoluer un peu
La norme est un outil très intéressant pour permettre (par exemple) de déterminer lequel de deux comportements est jugé "correct" par la forme si l'appel d'une fonction donnée (non modifiée) sur deux systèmes (au sens large

) réagissent différemment. Mais c'est malgré tout un document assez indigeste qu'il vaut mieux aborder selon l'optique du "je me pose une question, qu'en dit la norme

"

[EDIT]Grillé...

**minnesota** · 10/06/2010, 02h15

Envoyé par koala01

[EDIT]Grillé...

Peut-être, mais la lecture du contenu de ta réponse vaut vraiment le coup. L'attention avec laquelle tu la rédiges reflète quelque part la considération que tu portes à la question, et donc à son auteur. Je ne parle pas que pour moi, c'est un état de fait que j'ai eu le plaisir d'observer dans plusieurs discussions. Alors un merci tout particulier à toi. Et bien sûr, merci aussi à Luc et gl.

En ce qui me concerne, je code très peu, vraiment très peu. Mais même ce très peu, j'aime, j'ai envie qu'il soit parfait. Malheureusement, très vite, je cède à la facilité et je laisse de coté ces fameuses exceptions au profit des codes de retour. Bon, aussi certaines Lib contribuent à cette tendance. Comme je croyais les exceptions dépréciées, je pensais que le problème était réglé. Mais non. Alors, je voudrais bien m'y mettre sérieusement et j'en viens à me demander s'il existe un design pattern ou patron de conception qui serait à même de marier à la perfection ce genre de situation ? Par exemple, marier l'API Windows et ses suites de fonctions, ses codes de retour et son GetLastError() avec les exceptions d'un code C++ robuste.

Merci.

**minnesota** · 25/06/2010, 11h38

J'aurai bien voulu mettre un

**3DArchi** · 25/06/2010, 12h57

Regardes en bas de la discussion.

Magique, il y a le bouton

Approches ta souris et quand elle pointe dessus, dépêches-toi d'appuyer sur le bouton gauche

**minnesota** · 25/06/2010, 13h22

J’aurais bien voulu mettre un

mais je ne peux pas mettre de

parce que la discussion n'est pas totalement

.

Si on pouvait m'apporter une réponse à ma question, c'est avec plaisir que je suivrais à la lettre ton tutoriel :

Envoyé par 3DArchi

Regardes en bas de la discussion.

Magique, il y a le bouton

Approches ta souris et quand elle pointe dessus, dépêches-toi d'appuyer sur le bouton gauche

**Flob90** · 27/06/2010, 16h16

Envoyé par minnesota

Alors, je voudrais bien m'y mettre sérieusement et j'en viens à me demander s'il existe un design pattern ou patron de conception qui serait à même de marier à la perfection ce genre de situation ? Par exemple, marier l'API Windows et ses suites de fonctions, ses codes de retour et son GetLastError() avec les exceptions d'un code C++ robuste.

Il y avait eu une discusion sur le forum il y a quelques mois sur le choix exceptions/"codes de retour", il faudrait la retrouver, mais de mémoire une des conclusions était que les exceptions sont a utiliser pour les comportements exceptionnels, et que les codes de retour sont un bon choix quand le retour caractérise l'état du programme.
Sinon pour transformer les codes de retour en exceptions, tu pourrais encapsuler les fonctions de ta bibliothèqe dans des foncteurs, qui testeraient le retour et lancerais une exceptions si besoin. Mais je suis pas convaicu de l'utilité d'un tel système.

**3DArchi** · 27/06/2010, 18h14

Envoyé par Flob90

Il y avait eu une discusion sur le forum il y a quelques mois sur le choix exceptions/"codes de retour", il faudrait la retrouver,

à propos de "l'idiome GetLastError"

**minnesota** · 27/06/2010, 19h05

Je vais regarder la discussion de très près, au premier regard ça ne m'a pas l'air de voler bien haut mais c'est déjà ça.

Merci Flob90 et 3DArchi.

**zul** · 27/06/2010, 21h48

N'est-ce pas le propos de std::error_code et std::error_condition ? (ou boost::system::error_code ...) Il y'a des choses intéressantes à ce propos sur le blog du dev de boost::asio :

http://blog.think-async.com/2010/04/...0x-part-1.html

**minnesota** · 28/06/2010, 11h20

Excellent, ça se précise.

**Médinoc** · 28/06/2010, 13h41

Seulement, il arrive souvent que, dans cette fonction, tu fasse appel à... d'autres fonctions, et que ces fonctions puissent elles-même faire appel à d'autres...

Au bout d'un moment, il devient donc difficile de s'assurer qu'aucune des fonctions appelées ainsi "en cascade" ne lancera une autre exception qu'une... std::bad_alloc.

Or, si l'exception n'est pas rattrapée, elle peut parfaitement remonter jusqu'à... foo.

Le résultat est alors sans appel: comme foo ne peut "sortir" (sur exception) que suite à... une std::bad_alloc, le programme se trouve face à une exception inattendue et la seule chose qu'il puisse faire dans ce cas est, simplement de s'arrêter brutalement, en perdant, au passage, toutes les informations qui auraient pu être véhiculées par l'exception qui aura occasionné ce massacre

C'est pire: Il n'y a aucune vérification en compile-time, ni aucune optimisation: La mouture C++ des spécifications d'exceptions signifie en fait "appeler unexpected() (qui appelle terminate()) si une exception autre que celles-ci est lancée)". En gros, ça fait un try/catch supplémentaire qui crashe dans le catch(...).