Discussion :

[Jean-Marc.Bourguet]

En passant -- je crois l'avoir déjà dit mais j'ai la flemme de vérifier -- les exceptions sont une technique d'implémentation d'un choix de gestion des erreurs. Les codes d'erreur aussi. Suivant le choix fait quant à la manière dont les erreurs doivent être gérées, les exceptions rendent l'implémentation plus simple et plus sure -- moins de risques de bugs -- ou plus compliquée et fragile que les codes d'erreur. Il faut choisir d'abord ce qu'il y a a faire, ensuite la technique. Et il est sensé dans une même application d'utiliser les deux techniques suivant les erreurs à traiter et le contexte.

[Garulfo]

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).[...]
A mon avis, Ada95 et Ada05 sont des langages OO sans discussion possible.

L'article parle d'Ada.. pas plus de l'un que de l'autre. Et tu le dis toi même, il faut distinguer les choses. Introduire en disant qu'Ada est un langage OO sans mentionner que c'est les nouvelles moutures qui le sont, font que Wiki n'est pas une référence à suivre sans état d'âme. Mais je suis convaincu que tu le penses aussi.

Sans aller plus loin par la suite, je parlais de paradigme pas de technique: le polymorphisme et la surcharge sont des notions techniques. Quand tu dis que l'OO est une évolution naturelle du procédural, ce en quoi je suis parfaitement d'accord, tu te bases sur le paradigme et non la technique. Dans cette optique, Ada avec ses contrats et ses unités à un paradigme proche aussi. Menfinbon c'est vrai que pour le sujet on s'en fout un peu ^_^

Puis finalement je crois qu'on est essentiellement d'accord en plus.

[Luc Hermitte]

a- 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. »

b- 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).

c- 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

d- 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. ^_^

e- 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++.

a- C'est bien possible oui.

b&d- Oui et non. Les langages récents, ont tendance à s'approprier des éléments d'autres paradigmes OO comme exceptions (mais ce n'est pas toujours le cas: vimL (langage impératif interprété, utilisé pour scripter vim)) [Ah! Jean Marc a parfaitement exprimé mon idée]. Certes, cela n'aide pas à faire la distinction.
Et pourtant je l'avais faite lorsque j'avais enseigné le C++ il y a quelques temps -> "il y a aussi les exceptions, mais les exceptions, ce n'est pas OO".
Certainement la faute à ma formation (qui ne rentre pas dans ce que tu décris) : en 1ere année: 6mois d'Ada comme 1er langage, servant de support à l'initiation à l'algorithmie. Dans le lot, un gros TD (ou chapitre de cours?) qui présente les exceptions en Ada(83). D'où ma réaction de les dissocier profondément de l'OO. L'OO n'avait été vu que l'année suivante avec Eiffel -- depuis je me demande si OCaml et Java n'ont pas remplacé ces deux langages dans ma formation, mais c'est une autre histoire.

<relançons le débat >
e- N'est-ce pas aussi une question de public ? J'ai l'impression que beaucoup moins est attendu (en info) de quelqu'un dans une filière électro(/tech)nique/aéro/... que dans une filière info&maths. Le développement n'y est plus qu'un outil secondaire. Même si au final le jeune diplômé va se retrouver à coder (des choses liées à son métier) une fois dans l'industrie.
N'est-ce pas une des raisons du "les exceptions c'est secondaire" durant l'apprentissage? À cause de cette perception de "apprends d'abord à spécifier+coder ton algo pour les cas (scolaires) où tout va bien" ?
</>

c- Hé hé. C'est bien pour cela que j'ai précisé le "selon"

[Garulfo]

[...]
<relançons le débat >
e- N'est-ce pas aussi une question de public ? J'ai l'impression que beaucoup moins est attendu (en info) de quelqu'un dans une filière électro(/tech)nique/aéro/... que dans une filière info&maths. Le développement n'y est plus qu'un outil secondaire. Même si au final le jeune diplômé va se retrouver à coder (des choses liées à son métier) une fois dans l'industrie.
N'est-ce pas une des raisons du "les exceptions c'est secondaire" durant l'apprentissage? À cause de cette perception de "apprends d'abord à spécifier+coder ton algo pour les cas (scolaires) où tout va bien" ?

Tu as totalement raison. Et c'est là le problème.
Dans une filière pour devenir développeur dans le sens large, le fait de ne pas voir d'exception dans un premier cours d'informatique mais dans un cours dédié à des techniques n'est absolument pas dommageable. En 3 ans, l'étudiant a le temps d'apprendre et de voir bien des choses.

Par contre, dans des filières où l'informatique est un outil, on devrait au contraire centrer l'apprentissage de l'outil sur une pratique de celui-ci et donc bien enseigner les éléments pertinents relativement tôt. Le but n'étant pas de comprendre les éléments constituants, mais l'utilisation.

Je pense que beaucoup d'étudiants en informatique n'ont d'ailleurs pas compris ça. Ils espèrent qu'on va leur enseigner l'informatique comme on enseigne la mécanique automobile dans une filière professionnelle. Hors c'est plutôt comme on enseigne la mécanique au sens large en physique qu'on va leur enseigner l'informatique.

C'est comme les maths vu en mathématique ou les maths vu en informatique ou physique. Ce sont deux choses distinctes dans la manière de le voir. On l'a compris pour les maths, mais pas encore pour l'info.

[Emmanuel Deloget]

Rien n'empêche l'appelant à lancer une Dans l'interface d'une bibliothèque, par exemple, j'ai l'impression qu'elles sont rarement la meilleure solution.

Heureusement, ce n'est pas la vision des concepteurs de la librairie standard du C++ - qui ont défini un certain nombre de méthodes, opérateurs et fonctions générant des exceptions.

Il y a toujours un décalage entre la façon dont un langage est prévu pour fonctionner et la façon dont les gens l'utilisent, surtout si aucune piste n'est donnée par les concepteurs du langage. Si les concepteurs du C++ avait dit "les exceptions sont le mécanisme usuel de gestion d'erreurs", les programmeurs les auraient adoptées depuis longtemps. Au lieu de ça, on reserve les exceptions à des cas exceptionnels - ce qui n'est pas, à mon sens, la meilleure utilisation.

Il y a aussi une incohérence frappante entre ce que représente une erreur et ce que les programmeurs pensent qu'elle représente. Un programmeur C++ aura plus de facilité à dire "là, je retourne un code d'erreur parce que c'est plus rapide à traiter". A mon sens, c'est absurde - parce que traiter une erreur est, de toute façon, pénalisant - et rarement rapide. Rajouter à ça qu'on parle de temps qui sont difficilement mesurables (à moins d'être mauvais en architecture logicielle et de trouver mignon d'appeler une fonction générant une exception dans une boucle dont la vocation est d'assurer un maximum de performance au système) - et on se rends rapidement compte de l'énormité de l'erreur que l'on commet en mettant les exceptions de coté lorsqu'il s'agit de traiter des erreurs qui ne sont pas exceptionnelles.

A ce propos, dans (shameless plug) cet article, je donne l'exemple d'une fonction récursive - quel est le meilleur moyen de remonter une erreur : un code de retour (qui s'accompagne d'un code systématique de test) ou une exception ? Pour simplifier: quel est le meilleur code parmi ces deux snippets:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
error::code sg::node::render(rendering_context *context)
{
   for (int i=0; i<sons.size(); ++i)
   {
      error::code errcode = sons[i]->render(context);
      if (errcode != error::code::ok)
      {
        return errcode;
      }
   }
   return attached->render(context);
}

ou

Code :

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

1
2
3
4
5
6
void sg::node::render(rendering_context *context)
  throw (std::exception, renderable::exception)
{
   std::for_each(sons.begin(), sons.end(), std::mem_fun(&renderable::render));
   attached->render(context);
}

Au final, je crois que ma réponse à ce sondage est : "parce que les gens ne comprennent pas vraiment à quoi ça sert, et qu'ils sont empêtrés dans leur vision du langage".

[Sylvain Togni]

Heureusement, ce n'est pas la vision des concepteurs de la librairie standard du C++ - qui ont défini un certain nombre de méthodes, opérateurs et fonctions générant des exceptions.

L'usage des exceptions dans la librairie standard est quand même assez ... exceptionnel. Et lorsqu'on a le choix (vertor[i]/vertor.at(i), iostate/exceptions) ce n'est pas la version avec exception qui est la plus utilisée ni la plus idiomatique.

[bdeuu]

Si une vraie appli est obligée de s'arrêter 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.... )

Il y a une différence entre arrêter un traitement et arrêter une application.
Si toutes les conditions ne sont pas réunies pour que le traitement se passe correctement, une exception est générée, cette exception sera catchée x couches plus haut.
C'est un comportement sain.

Les gens qui fonctionnent avec des codes d'erreur, font remonter leur erreur de couche en couche, ajoute des tests dans toutes leurs méthodes et rendent leur code illisible.

[koala01]

Il y a une différence entre arrêter un traitement et arrêter une application.
Si toutes les conditions ne sont pas réunies pour que le traitement se passe correctement, une exception est générée, cette exception sera catchée x couches plus haut.
C'est un comportement sain.

Les gens qui fonctionnent avec des codes d'erreur, font remonter leur erreur de couche en couche, ajoute des tests dans toutes leurs méthodes et rendent leur code illisible.

Tu as sorti la citation de son contexte, et le contexte en l'occurrence était que souviron était d'accord avec ce que j'ai écrit.

Or, ce que j'ai écrit, c'est faut faire gérer l'exception par la fonction qui est en mesure d'apporter une (partie de la) solution au problème qui a provoqué le lancement d'une exception, et celui qu'il faut faire le distingo entre les problèmes majeurs et ceux qui peuvent n'etre, dans un premier temps, considérés que comme mineurs (à moins qu'il ne finissent au bout d'un certain temps par être considérés comme réellement majeurs).

Et, si hors contexte, on pourrait estimer que souviron fait peut être l'amalgame entre arrêter un traitement et arrêter une application, remise dans son contexte, son intervention a plutôt pour but de donner d'avantage de poids à mes écrits

[JolyLoic]

Les gens qui fonctionnent avec des codes d'erreur, font remonter leur erreur de couche en couche, ajoute des tests dans toutes leurs méthodes et rendent leur code illisible.

Faux. Là tu ne parles pas des gens qui fonctionne avec des codes d'erreur, mais des gens que ne fonctionne que avec des codes d'erreurs.

Les gens qui fonctionnent avec des codes d'erreur et des exceptions n'ont pas ce problème, et n'ont pas non plus le problème d'avoir un code lourd à lire et maintenir dans les cas où l'erreur peut être gérée localement. Quand j'ai deux outils à ma disposition, je choisi tâche par tâche lequel je vais utiliser, sans a priori métaphysique. La meilleur visseuse/dévisseuse au monde reste peu agréable à manier pour enfoncer des clous.

[souviron34]

et pour continuer d'appuyer les dires de mes 2 prédeccesseurs, encore la programmation du net :

les serveurs de connections contiennent le mélange des 2 notions :

• une erreur d'écriture sera un code d'erreur, et vraisemblablement bouclera avec un time-out.
  
  
• une erreur de connection (le client a fait un shutdown par exemple, ou un noeud entre client et serveur est tombé) sera traité par une exception, qui fermera proprement le socket et tentera éventuellement une reconnection (si c'est une appli bien faite), en bouclant là aussi sur un code d'erreur.
  
  On aura donc dans ce cas DANS l'exception la présence d'un code d'erreur AUSSI....

[reptils]

J'ai voulu testé vite fait une exception de base histoire de voir quel comportement ça a. Deja j'aimerais savoir si, par exemple sur un vector, l'appel de la méthode ".at(i)" est vraiment moins performante (en temps d'acces...) qu'un simple appel à l'opérateur "[i]" ? si on imagine qu'on boucle beaucoup sur les éléments de vectors ça peut devenir génant.
Est ce qu'un check de dépassement de tableau par un at(i) est aussi lourd que de faire soit même un if(i>...)?

EDIT: ah ouais j'ai vu dans le cours C++ de casteyde qu'on pouvait (dans le cas d'un allocation mémoire) faire un truc du genre

Code :

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

int* table=new(nothrow) int[taille];

pour ne pas levée une exception mais plutot retourner un pointeur NULL. mais si on précise (dans mon cas je gcc 3.4 de cygwin) l'option -fno-exceptions pourquoi ça ne me dispense pas de mettre le nothrow? j'ai testé avec cette option et sans le nothrow en allouant un truc dément, et j'ai un message "Hangup"... en gros il n'est pas content alors que si je met le nothrow, je récupère bien un NULL.

[Emmanuel Deloget]

J'ai voulu testé vite fait une exception de base histoire de voir quel comportement ça a. Deja j'aimerais savoir si, par exemple sur un vector, l'appel de la méthode ".at(i)" est vraiment moins performante (en temps d'acces...) qu'un simple appel à l'opérateur "[i]" ? si on imagine qu'on boucle beaucoup sur les éléments de vectors ça peut devenir génant.

Bien qu'il existe un accesseur [] dans la classe vecteur, je rappelle que les parcours de vector, list, etc sont de manière idiomatique réalisé via les iterateurs ("for(it=v.begin(); it != v.end(); ++it)" ou encore mieux, avec les algorithmes de la CSL). Ce qui permet d'éviter les erreurs du type de celle que tu décris. at() et l'opérateur [] sont censés être réservés à l'accès "random", pas l'accès séquentiel. Dans ce cadre, [] est lui-même censé être réservé aux cas ou, algorithmiquement, on est sur de taper dans le vecteur. At() est réservé aux cas ou l'index n'est pas sûr (on pour bien sûr s'arranger pour que l'accès au vecteur soit toujours correct).

Est ce qu'un check de dépassement de tableau par un at(i) est aussi lourd que de faire soit même un if(i>...)?

Oui. C'est ce code (ou quelque chose de très similaire) qui est utilisé.