Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ De l'usage des exceptions

De l'usage des exceptions

106 réponses
Avatar
Guillaume Gourdin
Bonjour à tous,

selon ma (modeste) expérience, les exceptions en C++sont très largement sous
utilisées, et on en reste (me semble t-il) toujours à la bonne vieille
méthode du retour d'un code d'erreur. Je suis un peu surpris de cet état de
fait, les exceptions étant supposées apporter une gestion plus performantes
des erreurs. J'ai dons quelques questions: est-il vrai que les exceptions
sont sous utilisées? Quels sont vos retours d'expérience? Ou bien y a t'il
une raison plus profonde à la sous-utilisation des exceptions?

Merci!

- Guillaume -
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
7 8 9 10 11
Avatar
James Kanze
On Jul 13, 11:26 am, (Marc Espie) wrote:
In article <4a4f3042$0$30992$,



Guillaume Gourdin wrote:



>selon ma (modeste) expérience, les exceptions en C++sont très
>largement sous utilisées, et on en reste (me semble t-il)
>toujours à la bonne vieille méthode du retour d'un code
>d'erreur. Je suis un peu surpris de cet état de fait, les
>exceptions étant supposées apporter une gestion plus
>performantes des erreurs. J'ai dons quelques questions:
>est-il vrai que les exceptions sont sous utilisées? Quels
>sont vos retours d'expérience? Ou bien y a t'il une raison
>plus profonde à la sous-utilisation des exceptions?



Apres avoir parcouru rapidement ce fil de discussion (une
semaine de vacances), je suis surpris de ne pas avoir vu de
plus visibles references a Herb Sutter. (ou alors, tout le
monde l'inclut de facon implicite ?). Ses divers travaux
(gotw, exceptional C++ et ses suites) sont quand meme
fortement centres sur la difficulte de faire des choses
correctes en presence d'exceptions... ce que j'en ai retenu,
c'est que si toute la chaine n'est pas super-propre cote
destructeurs, laisser des exceptions se propager n'est pas
raisonnable (deja, on a les destructeurs, et donc on echappe
au cauchemar du finally de java)



Le problème, c'est que cette complexité, c'est du tout ou rien.
Dès qu'il y a des exceptions, on l'a ; elle n'entre plus en
ligne de compte alors pour la décision si une fonction donnée
doit renvoyer une erreur par une exception ou par un code de
retour. Et dès qu'il y a des allocations dynamiques, il y a des
exceptions, au moins de remplacer le new_handler (ce que
beaucoup plus d'applications doivent faire). (En revanche, à
l'encontre de ce que j'ai lu ailleurs dans le thread, si tu
remplaces le new_handler avec un qui avorte, il n'y a plus de
risque d'une exception de la bibliothèque standard, au moins de
faire quelque chose exprès pour l'avoir.)

Bref, ca n'est que depuis peu (a tout casser 5 ans) que les
exceptions fonctionnent en C++.



Il n'y a pas une ligne nette. Tout dépend de l'application, des
compilateurs qu'il faut supporter, et des gens qui doivent
travailler sur le projet. (Dans beaucoup de cas, les exceptions
fonctionnaient dans le compilateur bien avant que les
programmeurs comprenaient ce que signifiait l'« exception
safety ».)

Pas tres surprenant qu'elles soient peu utilisees, surtout vu
la difference de mentalite cote programmation qu'elles
impliquent (pour avoir des exceptions, il faut vraiment faire
du C++, et plus du C ameliore...)



Oui, mais pour ça, il y a bien d'autres raisons aussi. Même sans
exceptions, je fais du C++, et non du C amélioré (et ça, depuis
1992, au moins -- et il n'y avait pas d'exceptions alors).

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
James Kanze
On Jul 13, 11:59 am, (Marc Espie) wrote:
In article ,
Fabien LE LEZ wrote:



>On Mon, 13 Jul 2009 09:26:16 +0000 (UTC), (Marc
>Espie):



>>Ses divers travaux (gotw, exceptional C++ et ses suites)
>>sont quand meme fortement centres sur la difficulte de faire
>>des choses correctes en presence d'exceptions...
>Certes, mais c'est relativement indépendant de la question
>qui nous occupe :
>- Presque n'importe quel code peut lancer une exception, donc
>ton code doit être exception-safe de toute façon, que tu
>lances toi-même des exceptions ou pas.



Non. Il y a des tonnes de projets que je connais qui
preconisaient et preconisent encore le -fno-exceptions. => ca
veut dire qu'il y a plein de projets qui interdisent
explicitement dans leur cahier des charges la levee
d'exceptions... et qui sont codes en consequence.



Evidemment, ca n'est pas toujours marque, mais je me garderai
bien d'utiliser des exceptions avec du code que je n'ai pas
ecrit si je n'ai pas quelques paragraphes dans la
documentation de ce code qui mentionnent explicitement la
gestion des exceptions.



Le problème, et c'est un vrai problème, c'est la documentation
des bibliothèques tièrces. D'une part, je comprends bien tes
hésitations à utiliser une bibliothèque qui n'a pas documentée
ces garanties. De l'autre, quelle position prendre si elle a
documenté que telle ou telle erreur sera signalée par une
exception ? Ou qu'elle n'a rien documenté, mais qu'elle utilise
manifestement std::vector ou std::string ? (Si une fonction
prend un std::vector<T>& en paramètre, et documente qu'elle met
son résultat dans ce vector, je partirais du principe qu'elle
peut lever une std::bad_alloc. Au moins qu'elle document qu'il
faut avoir remplacé le new_handler avec quelque chose qui ne
lève pas d'exception.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
espie
In article ,
James Kanze wrote:
On Jul 13, 11:26 am, (Marc Espie) wrote:
Pas tres surprenant qu'elles soient peu utilisees, surtout vu
la difference de mentalite cote programmation qu'elles
impliquent (pour avoir des exceptions, il faut vraiment faire
du C++, et plus du C ameliore...)



Oui, mais pour ça, il y a bien d'autres raisons aussi. Même sans
exceptions, je fais du C++, et non du C amélioré (et ça, depuis
1992, au moins -- et il n'y avait pas d'exceptions alors).



Attention, c'est une implication que je signalais. Il est clair qu'on
peut faire du vrai C++ sans utiliser d'exceptions. C'est le sens inverse
qui pose souci (utiliser des exceptions sans faire du vrai C++) ;-)
Avatar
espie
In article ,
James Kanze wrote:
Le problème, et c'est un vrai problème, c'est la documentation
des bibliothèques tièrces. D'une part, je comprends bien tes
hésitations à utiliser une bibliothèque qui n'a pas documentée
ces garanties. De l'autre, quelle position prendre si elle a
documenté que telle ou telle erreur sera signalée par une
exception ? Ou qu'elle n'a rien documenté, mais qu'elle utilise
manifestement std::vector ou std::string ? (Si une fonction
prend un std::vector<T>& en paramètre, et documente qu'elle met
son résultat dans ce vector, je partirais du principe qu'elle
peut lever une std::bad_alloc. Au moins qu'elle document qu'il
faut avoir remplacé le new_handler avec quelque chose qui ne
lève pas d'exception.)



Tu me rassures (en quelque sorte, en ne me rassurant pas). C'est exactement
le type de probleme epineux que je vois..
Avatar
Mathias Gaunard
On 4 juil, 12:34, "Guillaume Gourdin" wrote:

selon ma (modeste) expérience, les exceptions en C++sont très largeme nt sous
utilisées, et on en reste (me semble t-il) toujours à la bonne vieill e
méthode du retour d'un code d'erreur.



La raison principale à cela est que certains considèrent qu'écrire du
code exception-safe est compliqué (ou du moins beaucoup plus compliqué
que de gérer des codes de retour) ce qui est bien entendu absolument
faux, puisqu'au contraire écrire du code exception-safe basique est
trivial puisqu'il suffit de suivre le RAII. (si on doit gérer plein de
vieux code pourri ne suivant pas ce principe, par contre, c'est bel et
bien compliqué)
Le RAII va en effet garantir que le code sera robuste (de manière
basique uniquement, mais assez souvent de manière forte) aux erreurs
(erreurs levées par des exceptions) quoi qu'il arrive, ce qui n'est
certainement pas le cas de code écrit à la main gérant les erreurs qu i
sont exprimées par des codes de retour.

De plus, la levée d'exceptions dans les constructeurs permet d'établir
certains invariants pour des objets, plus celui-ci est fort meilleur
cela est pour la robustesse du programme.
Il est parfaitement acceptable par contre d'intégrer au sein de
l'invariant de l'objet la situation d'erreur, comme le font les
iostreams, si l'on considère que la situation d'erreur n'a rien
d'exceptionnelle. (et c'est très différent d'un système de codes de
retours)

Quoi qu'il en soit, du code ne suivant pas le RAII ou pire du code non
exception-safe est du code qui est bon à jeter selon moi, puisqu'il va
empêcher l'utilisation d'exceptions et n'est donc réutilisable qu'au
sein d'un dialecte ne les contenant pas.

On peut faire le choix de ne pas utiliser les exceptions du tout
(comme le fait Google), mais on ne peut pas mélanger du code non
exception-safe (donc du code présupossant qu'il n'y a pas
d'exceptions) avec du code levant des exceptions, ce qui en fait un
choix exclusif.
Avatar
espie
In article ,
Mathias Gaunard wrote:
On 4 juil, 12:34, "Guillaume Gourdin" wrote:

selon ma (modeste) expérience, les exceptions en C++sont très largement sous
utilisées, et on en reste (me semble t-il) toujours à la bonne vieille
méthode du retour d'un code d'erreur.



La raison principale à cela est que certains considèrent qu'écrire du
code exception-safe est compliqué (ou du moins beaucoup plus compliqué
que de gérer des codes de retour) ce qui est bien entendu absolument
faux, puisqu'au contraire écrire du code exception-safe basique est
trivial puisqu'il suffit de suivre le RAII. (si on doit gérer plein de
vieux code pourri ne suivant pas ce principe, par contre, c'est bel et
bien compliqué)



Ouais, ben dans la vraie vie, tu n'as generalement pas le temps de tout
ecrire de fond en comble, ni meme d'auditer serieusement le code que tu
reutilises... ca fait tout un ensemble de cas ou les exceptions sont
difficilement utilisables.

Ca n'empeche pas de suivre evidemment de bons preceptes pour que le code
nouveau fonctionne avec des exceptions... le jour futur ou tout le code
fonctionnera correctement !
Avatar
Michael Doubez
On 20 juil, 13:26, (Marc Espie) wrote:
In article .com>,
Mathias Gaunard   wrote:

>On 4 juil, 12:34, "Guillaume Gourdin" wrote:

>> selon ma (modeste) expérience, les exceptions en C++sont très larg ement sous
>> utilisées, et on en reste (me semble t-il) toujours à la bonne vie ille
>> méthode du retour d'un code d'erreur.

>La raison principale à cela est que certains considèrent qu'écrire du
>code exception-safe est compliqué (ou du moins beaucoup plus compliqu é
>que de gérer des codes de retour) ce qui est bien entendu absolument
>faux, puisqu'au contraire écrire du code exception-safe basique est
>trivial puisqu'il suffit de suivre le RAII. (si on doit gérer plein de
>vieux code pourri ne suivant pas ce principe, par contre, c'est bel et
>bien compliqué)

Ouais, ben dans la vraie vie, tu n'as generalement pas le temps de tout
ecrire de fond en comble, ni meme d'auditer serieusement le code que tu
reutilises... ca fait tout un ensemble de cas ou les exceptions sont
difficilement utilisables.



En partant du principe que les exceptions arrivent de façon
exceptionnelle et qu'utiliser du code moisi fait que, de toutes
façons, la qualité du logiciel s'en ressentira. Ca veut juste dire que
le jour où ça claque alors le logiciel est peut être dans un état
instable, avec quelques catch, il doit être possible de rattraper le
coup où de terminer de façon gracieuse.
Et si c'est pas le cas, on fait ce qu'on peut avec ce qu'on a; ce sera
pas le premier crash.

Je n'ai pas de stats mais je pense qu'il y a encore beaucoup de code
exception unaware dans la nature qui tourne bien la plupart du temps.
Et si une exception est lancée par la couche utilisatrice alors ça ne
devrait pas trop compter tant que les classes utilisées gérent
correctement leur état.

Ca n'empeche pas de suivre evidemment de bons preceptes pour que le code
nouveau fonctionne avec des exceptions... le jour futur ou tout le code
fonctionnera correctement !



Personnellement, sans parler d'exception, je trouve que RAII simplifie
le code et je suis plus tranquille, ça évite retracer les chemins
d'executions pour insérer le code au bon endroit.

--
Michael
Avatar
espie
In article ,
Michael Doubez wrote:
Personnellement, sans parler d'exception, je trouve que RAII simplifie
le code et je suis plus tranquille, ça évite retracer les chemins
d'executions pour insérer le code au bon endroit.




Bien evidemment. RAII, ca veut juste dire faire du C++, et pas du C
"mode objet". Mais bon, vu ce qu'on rencontre dans la nature... ;-<
Avatar
Michael Doubez
On 20 juil, 14:41, (Marc Espie) wrote:
In article com>,
Michael Doubez   wrote:

>Personnellement, sans parler d'exception, je trouve que RAII simplifie
>le code et je suis plus tranquille, ça évite retracer les chemins
>d'executions pour insérer le code au bon endroit.

Bien evidemment. RAII, ca veut juste dire faire du C++, et pas du C
"mode objet". Mais bon, vu ce qu'on rencontre dans la nature... ;-<



Quand on a pas les outils, RAII impose une foultitude de petites
classes, ce qui peut être énervant.
Quelques templates bien placés permettent de gérer ça (smart pointer,
guard, lock ...) mais tant que c'est pas en standard ça fait parties
de ces fonctions bien utiles qu'on traine de projet en projet.

Avec les lambdas, ça prendra une autre tournure.

--
Michael
Avatar
Fabien LE LEZ
On Mon, 20 Jul 2009 07:05:30 -0700 (PDT), Michael Doubez
:

Quand on a pas les outils, RAII impose une foultitude de petites
classes, ce qui peut être énervant.



Les classes qui servent souvent ne doivent pas être si nombreuses que
ça.
Les classes qui servent une seule fois sont très locales, donc pas
très lourdes à gérer -- on ne les traîne pas dans un .h.
7 8 9 10 11