Pourquoi si peu de gens utilisent'ils les exceptions en c++?

Bonjour à tous

Je suis bien d'accord avec ça :

Citation:

---

Envoyé par Jean-Marc.Bourguet

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.

---

Avec ça :

Citation:

---

Envoyé par Luc Hermitte

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.

---

mais aussi avec ça :

Citation:

---

Envoyé par Luc Hermitte

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.

---

Et donc pour conclure, avec ça :

Citation:

---

Envoyé par Jean-Marc.Bourguet

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.

---

Les exceptions, c'est ni le bien ni le mal, c'est un marteau. Et tant qu'on s'en sert pour planter des clous, ça va bien.

1- Ne pas utiliser d'exception à la place des asserts. Comme l'a dit Luc.

2- Ne pas utiliser d'assert à la place des exceptions.

3- Ne pas utiliser des exceptions en cas d'erreurs "normales", c'est à dire attendues et/ou qui vont se produire souvent, utiliser pour cela des retours d'erreurs, éventuellement par le biais d'objets complexes.

Dans tous les cas, on a raison de toujours tester tout ce qu'on suppose en écrivant le code.

Exemple :
Une fonction reçois comme paramètre un flux d'entrée pour écrire dedans, elle a raison de tester s'il est ouvert et s'il a déclenché une erreur. Et si le test est positif, elle a raison (d'asserter / lancer une exception / retourner une erreur) selon le cas.

Autre exemple :
Une fonction reçois un entier qui peut valoir 1, 2, 3 ou 4 (bon déjà on peut se poser la question de l'enum), elle raison (d'asserter / lancer une exception / retourner une erreur) si elle reçoit 5 ou -12 ou 768

Digression...

C'est toujours difficile d'établir la limite entre situation exceptionnelle et cas d'erreur possible. Parfois, j'avoue choisir un peu au pif, ou alors biaiser en rajoutant d'autres arguments pour me faciliter la décision.

Mais prenons un exemple débile: je suis la puce d'une carte bancaire, et l'on m'introduit dans un distributeur de billets. L'ordinateur du distributeur finit par me proposer un code PIN. Je peux le rejeter ou l'accepter, et j'ai plusieurs moyens pour le faire. Est-il approprié de lancer une exception? Je pourrais être tenté de le faire, car je suis inutilisable sans le bon code PIN, un peu comme un objet en C++ dont la construction échoue.

Cependant, ma spécification précise que je dois sauvegarder le nombre de fois où Mme Michu se trompe de code, afin de me bloquer au bout de trois erreurs. C'est donc que le cas "code erroné" était non seulement prévu, mais parfaitement valable en ce qui me concerne.

C'est décidé, j'utilise un bit de retour (les bits sont chers!)

L'erreur est humaine, c'est la vie. Un câble réseau se débranche, c'est la vie aussi. Une écriture du disque qui échoue pour un petit fichier dans le répertoire de l'utilisateur, c'est déjà beaucoup plus suspect: je peux compter sur les doigts de la main le nombre de fois que cela m'est arrivé...

Mes trois roubles.

Carl

Citation:

---

Envoyé par screetch

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.

---

C'est pourtant ce que je propose dans mon post (couche de bibliothèque épaisse demandant à transmettre l'info, mais interface de la bibliothèque où l'on estime que l'erreur va pouvoir être gérée immédiatement). Et attends que je recomptes... 2 bras, 2 jambes, je ne suis pas encore écartelé.

Citation:

---

Envoyé par screetch

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.

---

Il y a des cas où il est extrêmement improbable qu'une gestion non locale soit un dispositif adapté(1). Dans ces cas, je préfère gérer ce cas par code de retour que par exception, la seconde demandant généralement du code plus lourd pour être traitée.

(1) Parmi ces cas, la gestion locale de l'erreur consistera peut-être à lancer une exception, mais celle-ci contiendra le contexte dans lequel l'erreur s'est produite, et non pas l'information bas niveau brute.

Citation:

---

Envoyé par screetch

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.

---

Encapsuler du code, c'est d'abord définir le contrat entre l'appelant et l'appelé. Donc, quand on fait une bibliothèque dont on ne connaît pas toutes les utilisations, c'est faire des suppositions sur ce que voudra l'appelant. Les informations qu'il pourra donner, les valeurs qu'il s'apprête à utiliser en retour, la façon dont les erreurs seront gérées.

Salut,

Je me permet de revenir un peu tard sur

Citation:

---

Envoyé par screetch

<snip>
les codes d'erreur en valeur de retour c'est toujours le mal, qu'on se le dise.

---

Selon moi, rien n'est mauvais si c'est utilisé à bon escient, ou, inversement, tout peut être mauvais si c'est utilisé de manière irréfléchie.

Et cela s'applique à énormément de chose, que ce soit les codes d'erreur en valeur de retour, la récursivité, ou même, le terme honnis entre tous: le goto.

En effet, toutes les techniques disponibles présentent un point au delà (ou en deçà, selon le sens dans lequel on regarde) duquel le déficit qu'elle implique est supérieur au gain engendré.

Personnellement, j'apprécie énormément les exceptions s'il s'agit de mettre en oeuvre un processus de "rollback" sur une suite d'appels de fonctions dont une risque de rendre tout ce qui a été fait par les fonctions appelantes invalides.

Par contre, s'il s'agit juste de fournir le contexte, pour log par exemple, dans lequel une erreur qui est survenue mais dont tout le traitement a été effectué, je n'éprouve aucune gène à utiliser un code d'erreur (ou de non erreur)

Certains voudront - peut-être - faire valoir que le coût à l'exécution d'une exception est important, et que cela risque de nuire au final gravement aux performances, mais je leur répondrai simplement que, en définitive, on ne parle que de "quelques" fréquences d'horloges, et que s'il y a des gains à faire du point de vue des performances, il faut plutôt essayer de les trouver du point de vue de l'algorithme.

mais je ne suis pas sur de suivre. une exception peut etre utilisée comme valeur de retour, en la catchant directement dans l'appelant. mais cela permet aussi de considerer une operation comme une transaction, et de laisser l'appelant de l'appelant, ou encore plus loin, traiter l'exception.

pour faire cela avec un code de retour, il faut propager a chaque etage.

de plus, lorsqu une exception est levée pour une erreur, elle ne peut pas etre ignorée. combien de gens verifient le code de retour de sprintf? (la reponse est pas assez).

donc je ne vois pas bien l'utilité d'un code d'erreur, puisqu'on peut faire pareil avec une exception...

koala, on parle bien de quelques cycles mais dans TOUT le programme, y compris le code qui n'utilise pas les exceptions. c'est un argument recevable, peu determinant dans certains domaines mais important dans d'autres =)

Bon, ce sujet est long, il part un peu dans tous les sens alors je vais juste répondre à la question initiale.

Ce que je pense des exceptions de manière générale: prenons un programme C pure souche. A moins d'être un hello world, ce programme va plus que probablement manipuler des fichiers, des connexions réseaux, ou même simplement utiliser de l'allocation dynamique, bref tout un tas de chose susceptible de générer une erreur indépendamment de la façon dont a été programmé ce programme. En C on a pas 36 solutions, pour qu'une fonction signale une erreur, il faut qu'elle renvoie un code d'erreur. Si un fonction donnée renvoie une erreur, la plupart des fonctions l'utilisant devront elles aussi renvoyer une erreur (sauf si il y a un mode de gestion précis pour ce type d'erreur, mais nous supposerons que la majeure partie des erreurs doivent être relayées jusqu'à l'interface graphique pour être signalées à l'utilisateur). Avec ces éléments, je crois être en mesure de poser la règle suivante: toute fonction non triviale écrite en C doit gérer des erreurs en interne et renvoyer un code d'erreur. Vous ne me croyez pas? Allez donc prendre un quelconque code open source d'une applic sérieuse en C (genre sqllite, mais il y en a des milliers) et cherchez une fonction ne renvoyant pas de code d'erreur, juste pour le fun.
L'immense, le grandiose, le sublimissime avantage des exceptions est que l'on signale une erreur uniquement la où elle apparait et qu'on la gère uniquement la où on en a besoin, et ce avec une syntaxe concue pour. Ne venez pas me dire qu'il y a des cas où un code d'erreur est mieux, c'est faux et archi-faux. Conceptuellement c'est largement supérieur, point. Mais attention, il ne faut pas confondre erreur avec cas à gérer, ce n'est pas pareil. Par exemple, j'ai déja vu des développeurs lancer une exception si une recherche dans un tableau échoue. Je trouverais ça ridicule en temps normal mais après tout, ça peut se justifier. C'est ce qui fait une part de la difficulté d'utilisation des exceptions: fixer une limitte inflexible entre erreur et cas n'est pas possible, c'est souvent sujet à interprétation.

Maintenant pourquoi on les utilise pas plus que ça en C++? Je retiendrais quelques arguments précédemment évoqués:
- la lenteur: alors ça, c'est vraiment l'excuse miracle universelle foireuse. Non, je vous en prie, expliquez moi clairement pourquoi un code avec exception serait plus lent qu'un code gérant correctement toutes les codes d'erreurs (avec tous les if() nécessaires bien sur). C'est peut-être parceque dans la pratique vous ne gérez pas les codes d'erreur. Dans ce cas je comprends, il est bien connu qu'un programme rapide qui plante est bien mieux qu'un programme correct.
- l'exception safety: la c'est déja un peu plus légitime. Il faut reconnaitre que l'exception safety est difficile à gérer, et ce n'est certes pas la première chose qu'on nous apprend (on devrait). Même si on se forge un bon coding-style, à grand coup de stl et boost, il reste encore le problème de l'utilisation de biblios C.
- la clarté (pas vraiment évoqué mais je sais que pour certains ça pose problème): la où un code d'erreur vous fait culpabiliser quand vous ne le gérer pas, une exception peut passer plus ou moins inaperçue, c'est un gros problème des exceptions non catchées en C++. En java nous avons deux types d'exceptions: les errors (équivalent d'un logic_error dans la stl) fonctionnent comme en C++, cela regroupe les erreurs de logique (qui n'apparaissent que si l'utilisateur d'une biblio fait une erreur dans sa programmation, cela devrait toujours être détecté pendant la phase de test) et les erreurs vraiment exceptionnelles (dépassement de la RAM). Puis nous avons les exceptions en tant que tel (runtime_error) qui sont toujours catchées, ce qui veut dire que si ce type d'exception est susceptible de se produire dans une méthode elle doit soit la gérer soit la relancer. La gestion des exceptions en Java a des inconvénients (c'est souvent énervant à gérer) mais a aussi comme avantage de permettre une très bonne auto documentation du code. En C++, on est réduit à devoir spécifier dans sa documentation toutes les exceptions susceptibles d'être lancées par chaque fonction. Ce n'est pas vraiment plus difficile mais cela demande pas mal de rigueur (perso, il faudrait que j'en aie plus :D).

Citation:

---

Envoyé par zais_ethael

- la lenteur: alors ça, c'est vraiment l'excuse miracle universelle foireuse. Non, je vous en prie, expliquez moi clairement pourquoi un code avec exception serait plus lent qu'un code gérant correctement toutes les codes d'erreurs (avec tous les if() nécessaires bien sur). C'est peut-être parceque dans la pratique vous ne gérez pas les codes d'erreur. Dans ce cas je comprends, il est bien connu qu'un programme rapide qui plante est bien mieux qu'un programme correct.

---

comme ecrit plus haut, les exceptions necessitent un "setup" de la pile pour pouvoir appeler les destructeurs. et c'est fait dans toute les fonctions, y compris celles qui ne lancent pas d'exceptions ou n'en catchent pas, ou ne sont pas non plus entre le lancement de l'erreur et sa gestion.

si la gestion de l'erreur a le meme cout, le fait que ce soit présent partout dans le code est different.

Citation:

---

Envoyé par screetch

koala, on parle bien de quelques cycles mais dans TOUT le programme, y compris le code qui n'utilise pas les exceptions. c'est un argument recevable, peu determinant dans certains domaines mais important dans d'autres =)

---

Cela ne va pas sans rappeler le nombre incroyable de débats sur "l'optimisation du code" que l'on a pu croiser...

J'ai toujours soutenu que, si tu as optimisé ton algorithme, tu n'as plus à t'inquiéter de gagner quelques cycles, même si tu peux t'arranger pour gagner ces quelques cycles au sein de l'ensemble des fonctions utilisées, quelles que soient les circonstances, et je n'en démordrai que quand la preuve du contraire m'aura été apportée.

Citation:

---

Envoyé par zais_ethael

Ne venez pas me dire qu'il y a des cas où un code d'erreur est mieux, c'est faux et archi-faux.

---

Non, tout dépend du contexte...

Je serais d'accord avec le fait qu'il ne faut pas les utiliser s'il faut faire remonter une erreur en vue de traitement d'annulation, mais si, tout traitement d'annulation effectué, le but du rapport d'erreur est "simplement" de permettre une gestion "pour mémoire", je ne vois pas pourquoi un code d'erreur ne serait pas suffisant ;)

Citation:

---

Envoyé par koala01

Cela ne va pas sans rappeler le nombre incroyable de débats sur "l'optimisation du code" que l'on a pu croiser...

J'ai toujours soutenu que, si tu as optimisé ton algorithme, tu n'as plus à t'inquiéter de gagner quelques cycles, même si tu peux t'arranger pour gagner ces quelques cycles au sein de l'ensemble des fonctions utilisées, quelles que soient les circonstances, et je n'en démordrai que quand la preuve du contraire m'aura été apportée.

---

dans mon metier ca s'appelle une frame par seconde =)

Citation:

---

Envoyé par zais_ethael

- la lenteur: alors ça, c'est vraiment l'excuse miracle universelle foireuse. Non, je vous en prie, expliquez moi clairement pourquoi un code avec exception serait plus lent qu'un code gérant correctement toutes les codes d'erreurs (avec tous les if() nécessaires bien sur).

---

Bien que ce ne soit pas l'argument que j'utilise généralement pour justifier mon choix, il y a des cas où il peut réellement intervenir. Et plus encore dans des langages où l'objet d'exception peut être un objet long a créer (ce qui n'est pas trop le cas avec les exceptions C++ standard). Dans du vrai code, en C# (ou l'objet d'exception embarque entre autre une copie de la pile d'appel au moment de l'exception...), on a eu une amélioration notable et visible par l'utilisateur en remplaçant du code genre :

Code:

---

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

Dictionnary<string, string> dict; foreach(string s in elements) { try { result.add(dict[s]); } catch { result.add("Error"); } }

---

par un :

Code:

---

1 2 3 4 5 6 7

Dictionnary<string, string> dict; foreach(string s in elements) { string trad = "Error"; dict.TryGetValue(s, out trad); result.add(trad); }

---

Une petite correction sur ton exemple de code :

Code:

---

1 2 3 4 5 6 7 8

Dictionary<string, string> dict; foreach(string s in elements) { string trad; if(!dict.TryGetValue(s, out trad)) trad = "Error"; result.add(trad); }

---

Citation:

---

Envoyé par screetch

dans mon metier ca s'appelle une frame par seconde =)

---

Hé bien, je suis loin d'être tout à fait convaincu.

D'abord, parce qu'il y a énormément de chances pour qu'une grosse partie de ce qui pourrait justifier le lancement d'une exception ou le traitement de celle-ci s'effectue à un moment où la nécessité de performances à l'affichage est moindre (chargement de fichiers, création d'objets, organisation des données)

Ensuite, parce que, même sur un 80086, il faut perdre 10.000 cycles pour ne perdre "que" 1 ms

Alors, oui, je suis d'accord que, si tu effectue 100 fois une boucle dans laquelle tu perd 100 cycles, tu arrives effectivement aux 10.000 cycles perdus, mais faut il te rappeler que les processeurs sur lesquels on travaille fonctionnent à des fréquences largement plus élevées que le 80086 :question:

Je suis d'accord qu'à ce rythme, on finira toujours par trouver une image qui "saute", mais, ne crois tu pas que, en optimisant l'algorithme, et en limitant le nombre de fois où il faudra effectuer cette boucle, tu regagnerais très largement les 100 cycles perdus à chaque itération :question:

Encore une fois, je le redis: avant de partir à "la chasse aux cycles perdus", il faut commencer par s'assurer d'utiliser l'algorithme le plus efficace.

Le simple fait de passer d'un algorithme d'une complexité O(N) à un algorithme de complexité O(log(N)) si possible provoquera un gain de performance largement suppérieur à tout ce que tu pourrais gagner pendant ta chasse aux cycles perdus.

Je comprend cependant très bien qu'il n'est pas toujours possible d'améliorer l'algorithme, et qu'il faille parfois chercher à optimiser encore un peu les choses.

Mais, généralement, dans ces cas là, est préférable de trouver le "petit tronçon de code dans lequel on passe le gros du temps" et de s'appliquer à optimiser ces quelques lignes, avant de renoncer de manière systématique à des possibilités pour un gain de temps, finalement, minime.

Evidemment, je ne peux obliger personne à se rallier à cet avis, et j'accepte d'en discuter.

Mais c'est mon avis... et je le partage :D

c'est clair qu'avec les machines actuel les exeptions tu le sent pas vus l'infime temps que ça te fait perdre.

En revanche c'est ultra important dans l'embarqué et l'industriel ou parfois les microcontroleur ont pas une fréquence de calcul élevé et il est préferable de tout coder en C.

Mais sincerement pour des application descktop je voi aucune contrainte au C++.

Les exceptions sont *plus* rapides que des if/else et des valeurs de retour dans le cas du chemin d'exécution sans erreur (98% des cas).
Par contre, ça fait un code plus gros...

Salut,

Il y a quelques semaines je me suis posé la question pour mon application : codes d'erreur ou exceptions ? Tout était implanté en code d'erreur et ca devenait ingérable. J'ai essayé les exceptions (que je n'avais jamais utilisé) et ca m'a changé la vie. Le code est nettement plus lisible, j'ai pu supprimer 2 affreux goto, bref je suis très satisfait du résultat. Pour info j'ai trois couches dans mon appli avec la GUI au dessus qui doit afficher les erreurs.

Citation:

---

Envoyé par titoine1978

Il y a quelques semaines je me suis posé la question pour mon application : codes d'erreur ou exceptions ?

---

Le bien et le mal n'existent pas, il n'y a que des marteaux.

Question... toujours dans ma conversion du C en C++ depuis un peu plus d'un mois. Je me demandais si l'apprentissage des exception pouvais se faire bien en deuxième plan? est ce que le fait de pas connaitre le mécanisme des exceptions pose une "limite" au développement? Par ce que pour le moment je me suis focalisé sur le mécanisme de la libraire standard, de la STL bien évidement etc. et pour le moment je ne suis pas tellement tombé sur des exemples de code où les personnes utilisent les exceptions.

Très souvent, les exceptions sont à utiliser dans le cadre d'un événement qui survient, alors qu'il n'aurait pas du, qui est de nature à briser l'exécution normale de ton code.

La gestion des exception n'est en définitive pas *si* compliqué que cela, dans le sens où il suffit de placer "ce qui peut foirer" dans un bloc try et "ce qu'il faut faire si elle survient" dans un bloc catch, au niveau où il est le plus logique de réagir à cet événement non souhaité.

La bibliothèque standard fournit une série d'exceptions de base, et, finalement, si tu étudie la SL "à fond", tu passera d'office sur les exceptions ;)

Maintenant, comme tu peux le remarquer, le débat fait rage entre les retours avec valeurs d'erreur et les exception, et, finalement, tu pourrais tout aussi bien envisager de, tout simplement, t'assurer que ces événements non voulus ne surviennent jamais :P

Dés lors, j'aurais presque tendance à dire que les exceptions sont comme tout le reste: une manière de travailler qu'il faut connaître, mais dont l'utilisation doit être évaluée au coup par coup ;)

En terme d'apprentissage, les exceptions sont relativement indépendantes du reste, le principal point où elle interviennent, c'est de rendre absolument indispensable des techniques qui sans elles ne sont que très bonnes (Je pense au RAII par exemple). Donc, à mon avis, oui, dans ce cadre, elles peuvent être placées à la fin de l'apprentissage.

Par contre, il me semble nécessaire de les maîtriser avant de commencer un vrai programme. Ce n'est pas une chose qui peut s'ajouter à la fin, elles ont une influence sur l'interface d'une classe. Donc, si comme beaucoup, l'apprentissage s'articule autour de l'écriture d'un programme qui n'a pas pour objectif de partir à la poubelle dès l'apprentissage fini, je pense qu'il vaut mieux ne pas les repousser à trop tard.