Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
méconnaissance de leur potentiel
gestion du code de retour d'erreur plus pratique et plus efficace
raison historique : mise en place tardive dans la SL
problème de performances
un peu tout ça à la fois
autre
t'as rien compris
ne se prononce pas
Pourquoi si peu de gens utilisent'ils les exceptions en c++?
Récemment j'ai pu lire un code qui utilisait pour chaque retour de fonction un boolean supportant un code d'erreur. Bref pire que le terrible HRESULT de winerror.h.
Après avoir dit beurk, une énième question existentielle m'a traversé l'esprit.
Pourquoi les exceptions en c++ sont (ou me semblent) si peu utilisées ? Alors qu'en Java elles sont omniprésentes.
Y a t'il une ou plusieurs raisons à cela quel soit technique, historique, psychologique ?
Merci de votre éclairage.
1) une raison parfois invoquée est le cout des exceptions en C++, ce n'est pas gratuit au runtime. c'est pas la raison la plus employée mais c'est celle que j'utilise donc je la mets en 1
2) du point de vue programmation, beaucoup avancent que les exceptions ne font pas partie du flux normal d'instruction, a savoir qu'une exception est comme son nom l'indique exceptionnelle, et que c'est quelque chose qui ne devrait ps arriver dans le produit final
3) la difficulté d'ecrire du code exception-safe est phenomenale. que se passe t'il si on interromp une operation en cours ? on est alors dans un etat ni initial, ni final, mais on revient a l'appelant de la methode. souvent, il n'y a pas de bonne echappatoire, le code va immanquablement planter.
neanmoins les exceptions remplacent souvent avantageusement les valeurs de retour.
1/ Je ne suis pas sur que les exceptions soient si peu utilisees que cela. C'est peut-etre vrai a certains endroits et pas a d'autres.
2/ Perso, je trouve que certains les utilisent quand il ne faut pas; et ce genre de cas se retrouve, si j'ai bonne memoire, jusque dans la bibliotheque standard Java (exemple, jeter une exception si l'ouverture d'un fichier echoue). Et si les programmeurs Java suivent la tendance, il est possible que ce soit eux qui les utilisent trop.
3/ Si, c'est pas clair par les deux points ci dessus: la bonne question est "Quand est-ce qu'il faut utiliser des exceptions?" Ma reponse est "Si la fonction appelante a peu de chance d'etre celle qui va gerer la condition signalee. Dans le cas de l'ouverture d'un fichier, c'est la fonction appelante qui va generalement gerer l'erreur (en essayant un autre fichier, en rapportant une erreur).
Une autre explications, les compilateurs c++ ont tardé à implémenter la notion d'exception. Alors les développeurs ont appris le c++ sans exception et ont de la peine a y revenir.
C'est au moins mon cas.
Raymond
Vous souhaitez participer à la rubrique Réseaux ? Contactez-moi
CafuroCafuro est un outil SNMP dont le but est d'aider les administrateurs système et réseau à configurer leurs équipements SNMP réseau.
e-verbe
Ma page personnelle sur DVP.
oui mais en general on est pas son propre client. par exemple, un jeu charge la lib lua qui charge un fichier. ce n'est pas a lua de gerer le fait que le fichier n'existe pas, c'est au jeu. donc le chargement du fichier qui plante devrait lancer une exception non rattrappée par lua. sinon lua doit propager l'info que le fichier n'existe pas. si le fichier existe mais ne compile pas, lua doit renvoyer une autre information.
la jean marc tu emets une supposition que l'utilisateur va traiter lui meme un evenement et ce n'est pas forcément le cas.
Salut.
regarde ce thread
http://www.developpez.net/forums/sho...light=exeption
Au fait, puisque tu dis "pire", en quoi le HRESULT est-il mauvais?
Je rappelle que tous les langages compatibles COM ne sont pas capables de gérer les exceptions...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
C'est un principe d'interface. Lua ne doit pas transmettre une exception a travers une interface si la fonction appelante est celle qui va generalement gerer l'exception.Envoyé par screetch
tu n'as pas compris ce que je voulais dire.
une exception permet de ne pas se soucier de qui va traiter l'erreur. dans ton exemple, tu disais que pour l'ouverture d'un fichier qui echoue c'est l'appelant qui verifie et que donc il est possible de renvoyer un code d'erreur sans utiliser une exception. et je dis non, il existe des cas ou tu n'es pas le client direct de ton api d'ouverture de fichier. dans mon exemple, j'ai inseré lua; je voudrais dire qu'avec la surcouche lua, je souhaite quand meme que mon programme soit prevenu si le script n'existe pas.
la solution actuelle etant que lua forwarde l'erreur de l'echec d'ouverture de fichier, et ca je trouve que saylemal.
les codes d'erreur en valeur de retour c'est toujours le mal, qu'on se le dise.
Pour traiter le HRESULT on voit souvent un gros switch bien crade pour le comparer avec les constantes du winerror.h. Sachant qu'y en a plus de 1000 ! On voit vite qu'on peut arriver à des cas extrêmes.
Mais il est vrai que dans les langages ne gérant pas les exceptions cela peut s'avérer utile.
@Montgaulois: merci pour le thread. J'avais pas mis les bons mot-clés
Pour rappel ce lien riche d'enseignement : http://www.parashift.com/c++-faq-lit...html#faq-17.12
C'est aussi mon avis
En effet, c'est complètement contraire à la spécification de COM qui dit de traiter uniquement les codes pertinents, et considérer les autres comme E_UNEXPECTED.
En fait, c'est encore plus utile pour les langages qui supportent les exceptions, sauf C++: Le HRESULT est traduit en exception et normalement, vice versa.Mais il est vrai que dans les langages ne gérant pas les exceptions cela peut s'avérer utile.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
(relativement aux points soulevés par screetch)
2) Je ne suis pas d'accord avec la vision des "beaucoup" auxquels tu fais référence.
Pour moi elles servent à traiter les situations non nominales. Une rupture réseau est parfaitement possible dans un produit final. Une exception est parfaite en ce qui me concerne dans ce genre de situations. Et effectivement, pour faire remonter le problème à l'endroit qui va bien.
Un truc qui n'est jamais sensé se produire, si cela se produit, c'est que les algos/le code sont faux. Là, c'est le boulot des assertions en ce qui me concerne. On peut les doubler d'exceptions pour faire moins "laid" sur le produit en release, mais bon. C'est pas leur rôle premier. (d'ailleurs, ils n'ont pas une dualité à ce sujet en Java avec les checked et unchecked exceptions?)
Une exception sur un fichier qui ne peut être ouvert ne me choque pas. Si lors d'un traitement complexe comme un rejeu fichier de télémétrie archivée je ne peux ouvrir le fichier, je pête une exception que je traiterai à l'endroit qui va bien. Par contre, si je ne peux logger ce qui circule sur mes réseaux, tanpis j'ignore, c'est aux admins de nétoyer les disques. Tout dépend de ce qui doit être fait.
3) Je ne trouve pas qu'un code spaghetti (ou bourré de "if (pasbon) goto ERROR:;") soit plus simple à rendre atomique/leak-free qu'un code qui repose sur les exceptions. AMHA, c'est limite le contraire, le RAII aidant beaucoup.
Quant à moi je vois:
a- l'aspect psychologique ("on n'a pas appris avec", "c'est lent", ...) déjà soulevé
b- la difficulté inhérente à un domaine difficile et mal compris (ce qui renvoie en a-) -- les codes que je vois sont avant tout pensés en situation nominale. On retombe sur le point de la difficulté à traiter les cas non nominaux. Mais exception ou code de retour, cela ne change rien : les gens ne savent pas traiter ces situations. Souvent, c'est l'expérience liée au métier qui permet d'avoir une indication de comment les traiter (et quoi traiter) ; l'expérience développement/C++ enseignant comment mettre en oeuvre la gestion de ces cas non nominaux.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
Je pense aussi que c'est le manque d'expérience générale avec les exceptions qui prime. D'ailleurs, beaucoup d'autres arguments en découlent. Mais les exceptions ont aussi le désagréable avantage de rendre très visible la difficulté de la gestion d'erreurs. Du coup, on voit souvent tirer sur le messager...
Carl
Je dirais qu'il y a deux cas. Si la fonction appelée par l'utilisateur de lua n'a aucun rapport avec l'ouverture de fichier, il ne me semble pas choquant qu'une exception soit émise si l'ouverture échoue. Si c'est une fonction ouvrant un fichier, il sera plus simple que cette fonction ait un code de retour. Dans les deux cas, la façon dont lua reportera cette erreur dépend de l'interface de lua et de rien d'autre.
En interne à lua, l'erreur détectée par code de retour de la fonction bas niveau d'ouverture de fichier pourra être transmise sous forme d'exception ou par passage de retour de fonction dans les deux cas, ça dépend uniquement de l'épaisseur de la couche lua, pas de ce que sera au final son interface.
Et même si elle est transmise en interne de lua sous forme d'exception, et qu'on a décidé que l'interface de lua va générer une exception, il y a de fortes chances que ce ne soit pas la même exception, mais une exception indiquant le problème avec une sémantique au niveau de l'interface lua, pas au niveau de son implémentation (et éventuellement une donnée membre innerException qui reprend l'exception initiale).
Les prises de décisions absolues et dogmatiques sur un sujet technique, c'est le Mal incarné.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
ce n'est pas au concepteur d'une bilbiotheque de decider si c'est la premiere couche, la deuxieme ou la 42eme qui doit gérer le fichier non existant. de mon point de vue, une exception permet de laisser le vrai "gerant" de l'erreur s'en occupper, alors qu'un code de retour d'erreur doit etre géré immediatement.
une exception PEUT egalement etre gérée immediatement.
tout ce qui sert ici a expliquer pourquoi un code de retour d'erreur n'est pas si mal se base sur des suppositions sur l'appelant. c'est pas comme ca qu'on encapsule du code, il me semble.
Rien n'empêche l'appelant à lancer une exception si la fonction lui renvoi un code d'erreur qu'il ne sait pas gérer à son niveau.
Je n'ai pas cette vision qu'en C++ les exceptions son LA façon de gérer les erreurs. Elles conviennent à certaines situations, pas à d'autres.
Dans l'interface d'une bibliothèque, par exemple, j'ai l'impression qu'elles sont rarement la meilleure solution.
C'est exactement la même difficulté qu'avec les valeurs de retour, sauf qu'avec les exceptions cela peut s'automatiser et se programmer plus élégamment et de manière plus performante.3) la difficulté d'ecrire du code exception-safe est phenomenale. que se passe t'il si on interromp une operation en cours ? on est alors dans un etat ni initial, ni final, mais on revient a l'appelant de la methode. souvent, il n'y a pas de bonne echappatoire, le code va immanquablement planter.
À noter, néanmoins, que les outils d'analyse statique se débrouillent mieux avec des if dans tous les sens qu'avec des exceptions.
je pense que si j'avais dit "rien n'empeche l'appelant de capturer l'exception et de la transformer en code d'erreur" tout le monde m'aurait ecartelé sur la place piblique. je me demande pourquoi ca serait plus valable de faire ca.
Toute conception d'interface se base sur des hypotheses sur la maniere dont elle sera utilisee. Je ne vois donc pas de problemes a choisir ma gestion d'erreur sur base de ces memes hypotheses.
J'ai utilise des interfaces qui utilisaient un autre mecanisme que des exceptions quand les exceptions auraient mieux convenus, c'est infernal. J'ai utilise des interfaces qui jetaient des exceptions quand un autre mecanisme aurait mieux convenu. C'est tout aussi infernal. A chaque fois, c'est des interfaces pas adaptees a l'usage que j'en faisais et donc mal concues pour cet usage.
Répondre avec citation
Partager