Discussion :

[screetch]

lorsque je ne sais pas, je m'en remets a Joel on Software;

http://www.joelonsoftware.com/items/2003/10/13.html

joel dit : utilisez des codes de retour.

et donc, comme dans 99,9% des cas, je suis entierement PAS d'accord avec joel.

neanmoins il semble assez ecouté donc je livre le lien

[screetch]

j'en profite egalement pour vous renvoyer sur quelques details interessants, dans un des nombreux GOTW consacres aux exceptions :
http://www.gotw.ca/gotw/020.htm
http://www.gotw.ca/gotw/021.htm

[Mat007]

Un peu de lecture supplémentaire sur le sujet : http://www.objectarchitects.de/arcus...ook/exhandling

MAT.

[bdeuu]

J'ai du mal a comprendre pourquoi l'utilisation des exceptions suscitent autant de désapprobations dans les rangs des développeurs C++.
Les exceptions permettent de séparer totalement le comportement nominal d'une application et la gestion des éventuelles cas d'erreur.
En cas d'erreur le traitement doit être stoppé, je ne vois pas d'exemple qui contredise cette affirmation.

[jpouly]

J'ai du mal a comprendre pourquoi l'utilisation des exceptions suscitent autant de désapprobations dans les rangs des développeurs C++.
Les exceptions permettent de séparer totalement le comportement nominal d'une application et la gestion des éventuelles cas d'erreur.
En cas d'erreur le traitement doit être stoppé, je ne vois pas d'exemple qui contredise cette affirmation.

Je suis d'accord avec toi. Trop longue discussion sur les exceptions en C++. En java et C#, ça n'aurais pas eu de succès.

Les codes retour c'est bien, mais on peut les ignorer. Avec les exceptions (du moins en java et .net), on peut forcer le développeur a utiliser un bloc try/catch. (De plus, on ne met jamais de bloc try/catch dans une boucle, comme j'ai lu plus haut).

Les exceptions sont nécessaires et obligatoires, à mon avis, lorsque l'on sort du périmètre de l'application. Après tout, c'est une histoire de confiance dans les api du système d'exploitation ou de la base de données, ou de la couche réseau, ou tout ce qui fait que le programme peut planter, à l'insu de son plein grès.

Ce qui m'étonne (enfin pas tellement après avoir vu quelques écrans bleus sous windows CE), qu'on me dise qu'en automatisme, on évite les exceptions. J'espère que le soft du tgv ne partira pas en core dump () lorsque je serais à bord. J'ose même espérer que c'est pas pour ça que les régulateurs automatiques se mettent à déconner

[Garulfo]

[...]
Une des raisons principales est qu'on ne ma jamais appris à les utiliser au cours de mon cursus (universitaire). Il faut dire que certains concepts clés du c++ étaient à peine abordés (la STL notamment) de la licence (L3 actuelle) jusqu'au Master. Pourquoi ce chapitre est t'il systématiquement (ou casi-systématiquement) passé à la trappe lors d'une formation c++ ? [..]

J'aimerais te donner des éléments de réponses à ta question.

D'abord il faut voir si le cours que tu as suivi est vraiment un cours de C++. Beaucoup de cours disent faire du C++, mais sont avant tout des cours de première programmation. Dans ce cadre, on n'essaye pas de tout voir parce qu'on ne peut généralement pas: comment comprendre le pourquoi et le comment des exceptions quand on ne comprend pas ce qu'est la programmation structurée, le flux des données et le traitement d'une erreur. De plus, on se fout en fait de faire du C++. C'est plus pour faire plaisir aux étudiants et aux employeurs de stages (dans notre cas) que pour une raison académique.

De plus, en général, à tort ou à raison, on commence avec du procédural. Parfois c'est le C++ qui sert à montrer le procédural... Donc les exceptions n'ont pas leurs places. À mon avis on devrait alors faire du C, ou mieux du pascal... menfinbon.

Si tu vois un vrai cours d'orienté-objet et que celui-ci se trouve être en C++ (ce qui est loin d'être une évidence) alors le cours devrait intégrer la gestion des erreurs par exceptions. Dans ce cas, on peut souvent mettre ça sur le dos du programme académique: que les raisons soient bonnes ou non. À ma connaissance, les cours d'OO que je connais intègre tous le traitement des exceptions.

[ac_wingless]

<...>J'ose même espérer que c'est pas pour ça que les régulateurs automatiques se mettent à déconner

Les régulateurs se mettent à déconner au fur et à mesure qu'on avance vers les 11 points de perdu

[Jean-Marc.Bourguet]

De plus, en général, à tort ou à raison, on commence avec du procédural.

Je suis globalement d'accord avec ce que tu ecris, mais je ne vois pas en quoi se limiter a la programmation procedurale empecherait de voir les exceptions.

[Garulfo]

[...]
Les codes retour c'est bien, mais on peut les ignorer. Avec les exceptions (du moins en java et .net), on peut forcer le développeur a utiliser un bloc try/catch. (De plus, on ne met jamais de bloc try/catch dans une boucle, comme j'ai lu plus haut).

COmment tu fais pour forcer le développeur à mettre un try/catch en Java ?
Et quand tu dis, on ne met jamais, tu sous-entend « un bon développeur » je suppose

[...] J'espère que le soft du tgv ne partira pas en core dump () lorsque je serais à bord.

Je vais te rassurer pour ce genre de chose. D'une part, je parie que les partis sensibles du TGV sont codées en ADA (du moins c'est le cas à la RATP, et je suppose donc, peut-être à tort, qu'il en est de même à la SNCF), d'autre part, en règle général, quand une partie touchant la sécurité à un problème, le système s'arrête pourt tout ce qui est train, métro ou chose du genre (pas les avions bien sûr ça ferait mal )

[Garulfo]

Je suis globalement d'accord avec ce que tu ecris, mais je ne vois pas en quoi se limiter a la programmation procedurale empecherait de voir les exceptions.

Ça n'empêche pas. C'est juste nullement dans la philosophie du procédural. Mais de toute façon, ce n'est pas non plus à proprement parler dans le paradigme OO. Je parlais juste d'usage classique. J'ai pas été clair : « pour beaucoup de personnes, les exceptions n'ont pas leurs places »

[koala01]

J'ai du mal a comprendre pourquoi l'utilisation des exceptions suscitent autant de désapprobations dans les rangs des développeurs C++.
Les exceptions permettent de séparer totalement le comportement nominal d'une application et la gestion des éventuelles cas d'erreur.
En cas d'erreur le traitement doit être stoppé, je ne vois pas d'exemple qui contredise cette affirmation.

Ce n'est pas aussi simple que cela...

Je suis d'accord que le traitement en cours doit être stoppé, mais la véritable question à se poser est "jusqu'où "

Une erreur peut avoir plusieurs origines, humaines (en ce y compris du fait du programmeur) autant que "systémiques".

Celles qui sont du fait d'une mauvaise implémentation de la part du programmeur devraient sans doute arrêter l'ensemble du processus et *idéalement* n'apparaitre qu'en phase de débuggage/test, car ces erreurs sont de nature à provoquer des incohérences au niveau des données. Les assertions classiques sont alors une alternative tout ce qu'il y a de plus valable.

Parmi celles que j'ai qualifiées de "systémiques", et dont certaines peuvent AUSSI être d'origine humaine, il faut faire la part des erreurs qui peuvent n'être que "temporaires" de celles qui ne pourront pas être rattrapées par l'application et qui seront donc "irrécupérables".

Parmi les erreurs "temporaires", certaines peuvent être traitées par l'application (tentative de récupération d'un peu de mémoire par l'application elle-même, réinitialisation d'une connexion dont l'application a la responsabilité, ...), et d'autres peuvent "tout simplement" être résolues en attendant simplement un tout petit peu:

En cas de time out d'un serveur ou de blocage d'un fichier par le système d'exploitation, il peut suffire d'attendre que le serveur soit un peu moins surchargé ou que le système d'exploitation libère l'accès au fichier, mais on peut estimer qu'au delà d'un point donné, ces erreurs soient considérées comme "irrécupérables".

Tant que ces erreurs ne sont pas considérées comme irrécupérables, il n'y a - a priori - aucune raison pour mettre fin à l'application.

Les erreurs que j'ai qualifiées d'irrécupérables peuvent aller jusqu'à nécessiter une intervention humaine: absence d'un fichier requis, média ou périphérique non trouvé, débranché ou en panne, câble débranché, ...

Chacun des cas que j'ai exposé en bref ici est susceptible de faire "casser le flux normal d'exécution" d'une application, mais la réaction de l'application face à cette cassure du flux normal d'exécution peut être variée, et peut nécessiter de faire remonter ou non une information particulière.

Il n'est pas exclu qu'une simple valeur d'erreur puisse suffire à donner suffisemment d'informations à l'application pour permettre à l'application de réagir correctement face à cette cassure du flux d'exécution normale... et, dés lors, je ne vois - a priori - pas de raison d'avoir recours à autre chose.

Dans d'autres cas, il se peut que les informations à faire "remonter" soient plus "complexes" qu'une simple valeur d'erreur, et les exceptions sont clairement la solution à préférer pour faire remonter ce genre d'information.

Comme je l'ai déjà fait valoir, les exceptions sont comme de nombreux autres concepts/ instructions:

Dans certains cas, leur utilisation est nécessaire, et elles devront donc être préférées à toute autre solution

Dans d'autre, leur utilisation est simplement utile, et leur utilisation peut ne dépendre que du bon vouloir du programmeur

Dans une troisième série de cas, enfin, leur utilisation peut être tout à fait inutile - voire "contre productive" - et il faudra préférer une autre solution.

[dédé]

Bonjour,
Perso j'ai implémenté des exceptions dans une classe, au début j'ai eu beaucoup de mal à m'y lancer. Je viens du C et on ne voit pas trop l'interrés de faire des exceptions alors qu'on a fait des 100taines de programmes sans.
Deplus quand on implémente ces machins, c'est chaque fonction de toutes les classes que l'on doit traité pour peu que la classe mère doive remonté des exceptions. Donc en temps de code on passe autant de temps à coder les fonctions que les erreurs.
Mais franchement c'est un outil puissant! On peut implémenter plusieurs classes d'exceptions qui ferons des choses différentes suivant ce que veut faire l'utilisateur ou la gravité de l'erreur, différents niveaux... On peut cibler exactement le point de départ de la levée d'exception(plusieurs classes imbriquées les unes dans les autres, qui a déclenché?) ça simplifie le débogage ...
On peut quand même renvoyer des chaines de caractères.
Plus besoin de tester tous les codes erreurs et des status à chaque commandes.
Je trouve que l'on peut gérer beaucoup plus facilement des objets.

Par rapport au temps d'exécution, vu la puissance des machines de maintenant, je ne vois pas bien, de plus effectivement cela ne doit gérer que les erreurs, or une erreur étant un déroulement anormale du programme on peut se permettre de prendre un peut de temps, surtout si c'est pour arrivé à un utilisateur qui doit cliquer sur un bouton.

En résumé c'est difficile de s'y mettre mais c'est puissant et utile, je pense.

[Luc Hermitte]

Deplus quand on implémente ces machins, c'est
a- chaque fonction de toutes les classes que l'on doit traité pour peu que la classe mère doive remonté des exceptions.
b- Donc en temps de code on passe autant de temps à coder les fonctions que les erreurs.

a- Non, ça c'est le C. Quand tu as un problème, tu dois remonter ton code d'erreur à chaque niveau.
b- je lis à mi-mots qu'en fait tes codes C ne se préoccupaient pas des cas où en fait il y avait des problèmes dans le flot d'exécution de tes programmes.

Sinon, pour revenir à deux messages plus haut, je ne vois pas en quoi les exceptions sont propres à l'OO (-> Selon wikipédia, Ada, et Lisp (parmi les non OO connus -- il y a aussi le VimL, que je dois être un des seuls à connaitre ici) disposent de fonctionnalités apparentées)

[koala01]

Bonjour,<snip>
Deplus quand on implémente ces machins, c'est chaque fonction de toutes les classes que l'on doit traité pour peu que la classe mère doive remonté des exceptions. Donc en temps de code on passe autant de temps à coder les fonctions que les erreurs.

Non, c'est chaque fonction qui est en mesure de réagir valablement face à une erreur qui doit envisager de récupérer l'erreur...

Si tu écris un code "propre", et que tu évites autant que faire se peut les effets de bords, il n'y a - a priori - aucune raison qui puisse justifier de mettre des blocs try catch dans toutes les fonctions qui font appel à une méthode "qui pourrait générer une exception"...

Du moment que tu capture cette exception quand tu as vraiment la possibilité de la gérer, ca reste tout à fait correct

Si, par contre, tu crée un code plutot crade qui risque lui-même de générer une autre exception qui devrait être gérée à un autre niveau, il est clair que tu va finir par avoir des try catch un peu partout

[dédé]

Citation:
Si tu écris un code "propre", et que tu évites autant que faire se peut les effets de bords, il n'y a - a priori - aucune raison qui puisse justifier de mettre des blocs try catch dans toutes les fonctions qui font appel à une méthode "qui pourrait générer une exception"...

Perso j'ai fais une classe qui implémente des protocoles de communications pour commander des périphériques. Si une erreur se produit, typiquement l'appareil ne répond pas, toutes les fonctions qui utilisent la fonction read doivent gérer l'exception pour la remonter tout en haut pour que l'utilisateur de la classe sache qu'il n'a pas reçu sa réponse.
Parce que on crée des reads évolués à partir de la classe héritée pour les différents périphériques. Et on veut savoir quelle fonction a générer l'erreur mais aussi quel périphérique.

Dans cet exemple précis je ne vois pas comment tu peux faire autrement? Impossible de gérer l'erreur en local dans la classe puisque le concepteur de la classe ne sait pas comment l'utilisateur de la classe va l'utiliser.

Me trompe je?

[koala01]

Mais, si tu sais de toutes manières que les méthodes ne sont pas en mesure de gérer les exception, contente toi de faire lancer les exceptions au sein de celles-ci, et place le try catch dans le code qui utilise la classe en elle-même... si c'est ce code qui peut gérer les exceptions

Et, en cela, le fait de faire un code propre correspond en réalité à veiller à ne pas faire d'allocation mémoire qui pourrait ne pas etre prise en compte lors du "nettoyage"

[Jean-Marc.Bourguet]

Si une erreur se produit, typiquement l'appareil ne répond pas, toutes les fonctions qui utilisent la fonction read doivent gérer l'exception pour la remonter tout en haut pour que l'utilisateur de la classe sache qu'il n'a pas reçu sa réponse.
...
Me trompe je?

A mon (pas humble du tout sur ce point) avis, si tu as souvent a faire des

Code :

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

1
2
3
4
5
6
7
 
try {
   ...
} catch (...) {
   doSomething();
   throw;
}

c'est que tu n'as pas compris quelque chose aux exceptions en C++. Et si c'est à chaque niveau dans une pile d'appel, c'est pire. Les exceptions sont la pour communiquer un problème entre couches. Si les couches intermédiaires doivent les traiter, c'est très mauvais signe. Si il n'y a pas de couches intermédiaires, c'est mauvais signe (ça arrive, mais c'est rare).

PS: je continue à penser que l'hypothèse sous-jacente à la question -- que les exceptions en C++ sont en général sous-utilisées -- est fausse.

[Garulfo]

[...]
Sinon, pour revenir à deux messages plus haut, je ne vois pas en quoi les exceptions sont propres à l'OO (-> Selon wikipédia, Ada, et Lisp (parmi les non OO connus -- il y a aussi le VimL, que je dois être un des seuls à connaitre ici) disposent de fonctionnalités apparentées)

Si c'est par rapport à moi que tu dis ça, ce n'est pas ce que j'ai dit, puisque j'ai précisé suite à l'intervention de Jean-Marc :
« Mais de toute façon, ce n'est pas non plus à proprement parler dans le paradigme OO. »

En fait, les exceptions font partis du paradigme de programmation par continuation. Ce n'est donc propre ni à l'OO ni au procédural. Simplement, si tu regardes l'ensemble des langages « classiques » tu reconnaitras que ce sont les langages objets qui implémentent principalement les exceptions. Le cas d'Ada est similaire car les paradigmes utilisées (contrats, modules) sont très proche de l'OO. Pour le Lisp et le Scheme, c'est vraiment par contre de la programmation par continuation qui est faite de manière explicite. Mais il est rare d'avoir un tel pouvoir sur les continuations en dehors de ces deux langages (et leurs héritiers).

Attention en citant Wiki... on sait bien que ce n'est pas très fiable. Si on lit les premières lignes concernant Ada, ce dernier est un langage OO

Bon sinon pour conclure, ce que j'ai dit c'est que dans l'esprit de beaucoup, programmeurs professionnels, étudiants, et prof compris, les exceptions sont essentiellement liés à l'OO. Ce qui explique qu'on ne les trouve pas dans les cours de programmation procédurale et qu'en général on les aborde dans les cours OO. ^_^

Mon message ne portait pas de jugement sur les bien-fondés des choix. Je faisais juste une constatation du pourquoi on voyait rarement des exceptions dans les cours « dit » de C++.

[souviron34]

En cas d'erreur le traitement doit être stoppé, je ne vois pas d'exemple qui contredise cette affirmation.

Les exceptions sont nécessaires et obligatoires, à mon avis, lorsque l'on sort du périmètre de l'application.

C'est que vous etes jeunes et n'avez travaille que sur des petites applis peu sensibles.

Je suis 100% d'accord avec koala01.


Si une vraie appli est obligee de s'arreter si il y a une erreur (meme grave), alors il y a pas mal de choses qui vont mal se passer (en particulier pour vous le net.... )

(pour rappel, le principe est que si une route (un serveur, un ensemble de serveurs) est down, on en prend une autre...)

[Jean-Marc.Bourguet]

Le cas d'Ada est similaire car les paradigmes utilisées (contrats, modules) sont très proche de l'OO.

Le coeur de l'OO, c'est un mélange de polymorphisme d'inclusion et de surcharge déterminée dynamiquement. Ada83 n'en a pas la combinaison des deux (il a un peu de polymorphisme d'inclusion et de la surcharge déterminée statiquement).

En fait, les exceptions font partis du paradigme de programmation par continuation. Ce n'est donc propre ni à l'OO ni au procédural. Simplement, si tu regardes l'ensemble des langages « classiques » tu reconnaitras que ce sont les langages objets qui implémentent principalement les exceptions.

On va citer PL/I... Mais de mon point de vue -- proche sur ce point de celui de Wirth et de Mössenböck, l'OO est l'évolution naturelle du procédural. Comme concept, ceux liés directement à l'OO sont plus intéressant que les exceptions même si la notion d'exception est plus vieille, donc il n'est pas étonnant qu'on ne la trouve que dans des langages qui se veulent relativement "complet" et présentent déjà ce qui est nécessaire à l'OO.

Attention en citant Wiki... on sait bien que ce n'est pas très fiable. Si on lit les premières lignes concernant Ada, ce dernier est un langage OO

A mon avis, Ada95 et Ada05 sont des langages OO sans discussion possible.

Bon sinon pour conclure, ce que j'ai dit c'est que dans l'esprit de beaucoup, programmeurs professionnels, étudiants, et prof compris, les exceptions sont essentiellement liés à l'OO.

L'esprit de beaucoup de ces gens est confu en ce qui concerne les concepts, techniques et modèles de programmation.