C++ : ​La gestion des erreurs avec les exceptions

Définir les bonnes pratiques

Testez gratuitement nos 1324 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Vous allez apprendre à prévenir des éventuels effets indésirables provoqués lors de la mise en œuvre des exceptions.
04:34

Transcription

Savoir utiliser les exceptions dans une application est une chose, encore faut-il le faire bien ! Nous allons maintenant aborder des points importants à respecter pour travailler sans mauvaises surprises avec les exceptions en C++. La première règle dit qu'on utilise les exceptions dans les constructeurs et pas dans les destructeurs. Dans les constructeurs, sauf le constructeur de déplacement, n'hésitez pas à utiliser les exceptions pour gérer les problèmes. Il est d'ailleurs difficile d'utiliser des retours de valeur, car il n'y a pas de type de retour dans un constructeur. Dans les destructeurs il ne faut JAMAIS déclencher une exception ! Ce n'est pas simplement un usage, il y a une raison très technique à ça. Lorsqu'une exception, quelle qu'elle soit, interrompt une fonction, les variables des fonctions un peu lentes ne traitant pas l’exception sont détruites en remontant la pile des appels des fonctions. Si ces variables ont un destructeur, il est appelé et le programme ne supportera pas que dans un de ses destructeurs, il y ait une exception pendant qu'il traite une exception. Il passerait alors dans l'état « terminate », qui lui serait fatal. Deuxième règle, utiliser le mot clé noexcept du C++ 11, pour signaler une méthode qui ne déclenche pas d'exception. Ce mot clé est informatif et n’empêche pas une exception dans la méthode. Il est surtout important de noter noexcept les membres liés à la sémantique de déplacement : le constructeur de déplacement et l'opérateur d'affectation de déplacement. Les destructeur peuvent être notés noexcept car il ne lèvent pas d'exception. Une autre bonne pratique est de faire dériver d'une classexception existante, vos exceptions. On l'a fait nous dans l'exercice du chapitre précédent. Vous pouvez dériver de exception de logic_error ou de runtime_error et ceci permet à ceux qui captent les exceptions, de faire des catch un peu plus génériques, des catch runtime_error par exemple, qui capteront votre exception et d'autres avec le même code. Une bonne pratique plus délicate et moins évidente, c'est éviter d'utiliser std::string dans vos classes d'exceptions. Cette recommandation est faite par Dave Abrahams qui est une référence dans la communauté C++, et il incite à formater les messages à la volé dans le e.what vous savez, qui retourne l'exception, plutôt que de stocker un message que l'on créerait au moment de l'exception car en créant ce message, on risquerait d'avoir à allouer de la mémoire et donc de générer une exception alors qu'on doit traiter une exception. Voilà pourquoi on doit éviter d'utiliser un std::string, si possible. Lever une exception doit aussi se faire avec une instanciation statique, comme on l'a toujours fait. Je le précise car si après la formation vous voyez des throw new_quelquechose, ne le faites surtout pas, par exemple, les MFC de Microsoft l'ont fait par le passé, c'est une source de fuite mémoire et vous auriez du mal à bien gérer les désalocations. Le Rethrow est un redéclenchement d'une exception déjà captée. On peut avoir besoin, après un traitement partiel de l'exception, de redéclencher cette exception pour quelle soit traitée au-dessus. La syntaxe que vous voyez là est la plus naturelle, mais ce n'est pas la bonne, elle pose des problèmes techniques. En effet une exception « e » est une donnée qui est présente dans la pile, et qui est recréée par le compilateur à chaque vidage de la pile quand remonte la pile dans le traitement de l'exception. Donc pour faire simple, gardez à l'esprit que « e » va changer et il ne faut surtout pas le stocker ou le réutiliser avec un throw. La bonne notation est celle-là et c'est celle qu'il faut utiliser. La différence est subtile Il faut écrire throw ; et non throw e ; ! Le compilateur ira chercher la bonne version de e pour la retransmettre. Dernier point, celui qui résume un peu tout ce qu'on a dit, rappelez-vous toujours cette formule : Une exception correspond à un problème précis. Il faut donc une réponse précise, c'est-à-dire un traitement spécifique à cette exception et à ce problème précis. Évitez ce que l'on voit malheureusement parfois trop souvent, un try catch d'une exception très générique avec dedans un pauvre log et plus le catch sera précis sur l'expression captée, et plus le traitement promet d'être sûrement très valable.

C++ : ​La gestion des erreurs avec les exceptions

Profitez des nombreux atouts des exceptions pour gérer les erreurs dans vos développements C++. Apprenez à les déclencher, les intercepter, les personnaliser, etc.

56 min (13 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Spécial abonnés
Date de parution :20 oct. 2016

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !