Discussion :

[souviron34]

je me permet d'intervenir legerement dans ce debat....

Comme il a ete dit, il faut prendre ce qui est adapte au langage et a la situation.

Cependant, pour avoir travaille sur moult programmes industriels 7/24/365, les exceptions dans ce cadre sont a BANNIR.....

Car en effet, comment peut-on garantir la continuite du traitement ???

D'ailleurs, je vous ferais remarquer que si c'etait si parfait, pourquoi sommes-nous oblige de re-cliquer sur un lien quand la connection n'a pas "pris" ??

La plupart des applis que l'on voit ces jours-ci avec ce genre de traitements sont de petites applis, qui "sortent" ou eliminent le traitement en cours lorsque quelque chose s'est mal passe.... MAIS quid de tout ce qui s'est bien passe et qu'il faut recommencer ????

Pour info j'ai trois couches dans mon appli avec la GUI au dessus qui doit afficher les erreurs.

Bah...

Code :

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

1
2
if ( RegisteredFunction (AFFICHE_MESSAGE) )
   CallRegisteredFunction ( AFFICHE_MESSAGE, ERROR, "il y a eu une erreur ici");

est pas vraiment complique...

...
prenons un programme C pure souche. ....
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.

voir ci-dessus

plus le fait que juste dans la routine au-dessus, par exemple tu ne rempliras pas une case d'un tableau, ce qui n'empeche pas que le reste du tableau est valide et continuer le traitement, contrairement aux exceptions....

C'etait mes 3 francs 6 sous

[reptils]

ok merci koala01 et JolyLoic, donc je terminerai de comprendre les concepts d'abstraction, template etc , meme si dans l'ensemble j'ai pas mal compris le mécanisme du c++. Il me reste pour le moment à mettre en pratique sur des petits tests, puis ensuite viendra le temps des exceptions. La difficulté est de trouver des exemples ou des exercices pour mettre en pratique les concepts de la STL et de l'orienté objet. Enfin va falloir que je jette un oeil a boost bien evidement, car je ne connais pas.

[Jean-Marc.Bourguet]

Cependant, pour avoir travaille sur moult programmes industriels 7/24/365, les exceptions dans ce cadre sont a BANNIR.....

Car en effet, comment peut-on garantir la continuite du traitement ???

Est-ce que tu peux expliciter ton raisonnement?

[iMaTh]

Dans l'indus, l'embarqué la robotique ect c'est pour 3/4 du temps du C de toute façon.

bon perso j'aime bien les exception, aprés faut que ça colle dans le projet, que la notions de temps a la µs ne rentre pas en jeu.

Actuellement je suis en projet a l'école et je fait des exceptions sur ce robot.


Et j'en conclue qu'il est preferable qu'il reflechisse une demie seconde et qu'il reparte plutot qu'il attend qu'un mec le debloque.

certes en C j'aurais pu le faire, mais le c++ était impossé et dans ce genre de projet c'est trés bien.

[souviron34]

Est-ce que tu peux expliciter ton raisonnement?

c'est assez simple.....

Ce que vous mettez (je ne te mets pas en cause , le "vous" est pour les posteurs ci-dessus) comme "avantages" des exceptions, qui est de ne PAS gerer de couche en couche les erreurs, signifie que la couche immediatement superieure, ou celle du dessus, n'est pas forcement au courant qu'il est arrive quelque chose pour un de ses elements...

Si il se trouve que cette couche fait une boucle "continue" sur les elements, son traitement sera pertube (pouvant aller jusqu'au crash) car elle ne sera pas au courant que quelque chose s'est mal passe...

Donc, meme si il s'agissait d'"objets" relativement independants, a moins que le traitement GLOBAL soit 100% objet "pur", des qu'il y a la moindre liaison (une liste chainee, une table, sans parler de l'influence de l'un sur le suivant) , si l'on veut que l'appli continue comme si de rien n'etait, en signalant juste une erreur, le fait de ne pas etre averti devient un inconvenient majeur....

Maintenant, comme je disais, ce n'est pas pour tout... Mais c'est suffisamment sensible pour ne pas avoir de positions dogmatiques comme celles que j'ai citees...

Un autre exemple : 99.99% des serveurs sur le web (dvp y compris) necessitent que l'on re-clique sur un lien si la connection a ete interrompue...

J'ai eu a developper des applis fonctionnant sans interventions humaines 7/24/365, et donc a inclure le traitement "on line" de ruptures de connections , et cela se fait parfaitement bien avec la gestion d'erreurs, puisque certaines fois soit les sockets "gelent" sans donner de signaux, ou d'autres erreurs, mais en tous cas l'utilisateur ne doit jamais re-cliquer..., et que donc c'est plus de la gestion d'erreur du read ou du poll ou du write que de la gestion d'exception (les read/write ressortent des codes d'erreurs, pas des exceptions).

Tout ca juste pour dire que la gestion d'erreurs peut avoir des avantages, la gestion d'exceptions aussi... Que cela depend des situations et des programmes...

[JolyLoic]

Je ne vois pas le lien que tu sembles faire entre exception et click... Ou alors j'ai mal compris ce que tu disais.

[koala01]

Souviron>> je ne vois pas bien ce qui pourrait t'empêcher d'écrire une boucle pertétuelle sous la forme de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Connection *conn=new Connection;
while(1)
{
    try
    {
        if(con->lost())
            throw ConMustBeRestarted();
        /* traitement */
    }
    catch(ConMustBeRestared &e)
    {
        /* éventuellement, écriture dans un log */
        /* libération correcte de la mémoire allouée à la connexion */
        delete conn;
        /* et relancement de la connexion */
        conn=new Conncexion;
    }
}

Maintenant, tu peux effectivement le gérer sous forme de rupture avec un simple code erreur

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
size_t error=0; /* pourrait très bien être une énumération ;) */
Connection conn=new Connection;
while(1)
{
    /* tout ce qui pourrait nécessiter de relancer la connexion */
    while(error==0)
    {
         /* tout va bien, on fait le traitement */
    }
    delete conn;
    switch (error)
    {
         case 1: /*time out */
            break;
         case 2: /* bad block*/
            break;
         /*...*/
    }
    conn=new Connection;
}

Il y aura, peut être, une option qui sera plus rapide que l'autre tant que la connexion est bonne, mais les deux options, dans l'absolu, tout à fait valides (bien que je n'aime pas trop l'idée d'un "while(1)... )

[Jean-Marc.Bourguet]

Tout ca juste pour dire que la gestion d'erreurs
peut avoir des avantages, la gestion d'exceptions aussi... Que cela depend
des situations et des programmes...

Je ne comprends pas pourquoi tu mets les deux au meme niveau en les
opposant. Les exceptions, c'est une technique d'implementation pour une
politique de gestion d'erreur donnee. Croire que toute gestion d'erreurs
doit se traduire par des exceptions ou que des qu'on utilise les exceptions on
s'interdit d'autres techniques de gestion des erreurs sont deux erreurs.

Ce que vous mettez (je ne te mets pas en cause
, le "vous" est pour les posteurs ci-dessus) comme
"avantages" des exceptions, qui est de ne PAS gerer de couche en couche les
erreurs, signifie que la couche immediatement superieure, ou celle du
dessus, n'est pas forcement au courant qu'il est arrive quelque chose pour
un de ses elements...

Si il se trouve que cette couche fait une boucle "continue" sur les
elements, son traitement sera pertube (pouvant aller jusqu'au crash)
car elle ne sera pas au courant que quelque chose s'est mal passe...

Donc, meme si il s'agissait d'"objets" relativement independants, a moins
que le traitement GLOBAL soit 100% objet "pur", des qu'il y a la moindre
liaison (une liste chainee, une table, sans parler de l'influence de
l'un sur le suivant) , si l'on veut que l'appli continue comme
si de rien n'etait, en signalant juste une erreur, le fait de ne pas etre
averti devient un inconvenient majeur....

Les exceptions (du C++, d'Ada -- d'autres langages PL/I, Eiffel si j'ai
bonne memoire ont un modele different) sont la pour signaler des erreurs
qui doivent interrompre le traitement en cours parce qu'il n'est plus
possible de le continuer. Apres chaque niveau decide ce qu'il doit faire
quand il est interrompu, les exceptions facilite beaucoup l'implementation
quand ce qu'il faut faire est d'interrompre egalement le traitement.

Un autre exemple : 99.99% des serveurs sur le web (dvp y
compris) necessitent que l'on re-clique sur un lien si la connection a
ete interrompue...

J'ai un gros probleme. Tu parles de serveurs, et pour autant que
je comprenne le probleme auquel tu fais allusion (tu as l'air de desirer une
notion de connection plus permanente que celle de TCP/IP), c'est un probleme
du protocole ou, a la rigueur, du client.

[souviron34]

Je ne comprends pas pourquoi tu mets les deux au meme niveau en les opposant.
...
Apres chaque niveau decide ce qu'il doit faire quand il est interrompu, les exceptions facilite beaucoup l'implementation quand ce qu'il faut faire est d'interrompre egalement le traitement.

Ce n'était pas ce qui était mis en avant dans la plupart des posts ci-dessus, sauf ceux de quelques auteurs (dont toi) :

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

J'ai un gros probleme. Tu parles de serveurs, et pour autant que je comprenne le probleme auquel tu fais allusion (tu as l'air de desirer une notion de connection plus permanente que celle de TCP/IP), c'est un probleme du protocole ou, a la rigueur, du client.

Non du tout...... Ce que je dis, c'est que "shit happens"... Mais que plutôt d'interrompre l'opération en cours et d'avoir à la recommencer AU NIVEAU DE l'UTILISATEUR, ce devrait être fait en bas... Voir ci-dessous :

Les exceptions (du C++, d'Ada -- d'autres langages PL/I, Eiffel si j'ai bonne memoire ont un modele different) sont la pour signaler des erreurs qui doivent interrompre le traitement en cours parce qu'il n'est plus possible de le continuer

je pense que justement, la notion de "parce qu'il n'est plus possible de continuer" est pervertie par ces mécanismes....

[koala01]

<snip>

je pense que justement, la notion de "parce qu'il n'est plus possible de continuer" est pervertie par ces mécanismes....

Je pense plutôt qu'elle est mal comprise ou mal perçue par certains...

Sans doute serait-elle plus claire si l'on rajoutait quelques termes pour que la notion devienne "parce qu'il n'est pas possible de continuer dans le flux normal d'exécution"

Parce que, en définitive, qu'il s'agisse d'un code d'erreur ou d'une exception, c'est bel et bien le but:

L'ouverture d'un fichier échoue il est impossible de continuer dans le flux normal d'exécution qui aurait été de faire des lectures ou des écritures.

Mais s'il est utilisé par l'application, elle peut très bien commencer par le libérer, avant de retenter l'ouverture

Une connexion échoue ou est suspendue il n'est plus possible de continuer dans le flux normal d'exécution qui aurait été de l'utiliser pour communiquer.

Mais, selon le cas, l'application peut attendre un certain temps pour permettre au système de réinitialiser la connexion et tenter "plus tard" de s'y reconnecter

Selon la raison qui a fait que l'erreur est survenue, qu'il s'agisse d'exception ou de retour d'erreur, il reste tout à fait possible, après avoir géré - si faire se peut (un fichier inexistant ayant peu de chances d'être recréé "par l'action du saint esprit" )- la cause de l'erreur, de relancer l'exécution avec l'espoir que cela réussisse cette fois, quitte à n'admettre qu'un nombre donné d'échecs successifs

[souviron34]

tout à fait d'accord

Mais il semble que le vocabulaire ait une influence sur la manière de penser .....

[koala01]

tout à fait d'accord

Mais il semble que le vocabulaire ait une influence sur la manière de penser .....

Ca fait des années que j'ai appris à me méfier des interprétations et des sous-entendus... en voici encore un exemple, dans le sens ou les termes "dans le flux normal d'exécution" devraient, dans la tête de toute personne un tant soit peu habituée à la programmation structurée, être d'office sous entendus

[befalimpertinent]

J'ai rajouté un sondage par rapport à la question initiale.
Merci d'y répondre (choix multiple autorisé)

[ac_wingless]

Pour limiter le biais, il manque l'option explicite "Je ne pense pas que les exceptions soient peu utilisées en C++".

[Médinoc]

Quand on développe une bibliothèque, je pense qu'il est important de laisser le choix à l'utilisateur d'utiliser les exceptions ou non. Un bon exemple pour cela est la classe Dictionary du framework .Net : Y accéder par l'opérateur [] peut lever une exception, alors que la méthode TryGet() retourne juste false en cas d'échec.

Cela permet d'adapter le code selon les cas:

• L'échec d'une recherche dans le dictionnaire peut être une condition normale qu'on veut traiter sans perte de performances (cache, options facultatives...)
• Ou peut être quelque chose qui n'est pas censé arriver et qui empêche le traitement (paramètre obligatoire, etc.)

[befalimpertinent]

Pour limiter le biais, il manque l'option explicite "Je ne pense pas que les exceptions soient peu utilisées en C++".

C'est vrai. Mais disons que ça rentre dans le cadre de "t'as rien compris". Je ne vous en voudrais pas

[koala01]

J'ai rajouté un sondage par rapport à la question initiale.
Merci d'y répondre (choix multiple autorisé)

J'ai voté "ne se prononce pas"... car, comme je les utilise quand nécessaire, comment pourrais-je savoir pourquoi ceux qui ne le font pas agissent ainsi

[befalimpertinent]

Je suis sûr que tu as un avis sur la question néanmoins

Pour mon expérience personnelle je ne les utilise pas (ou plutôt n'utilisaient pas - et oui je suis entrain de mis mettre ) par méconnaissance totale du sujet.

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++ ?
Je n'ai pas vraiment la réponse mais peut être qu'on ne considère pas ce chapitre comme essentiel ou peut être qu'étant considéré comme à part par rapport au flux normal du traitement des données il est tout simplement laissé à ceux que ça intéresse.

L'autre raison est que m'étant plus auto-formé au travers de livres et de sites web je n'ai jamais vraiment eu l'impression que les exceptions était très intégrés au autres concepts du c++ mais au contraire toujours traitées comme sujet à part. Sans oublier que la plupart des codes que j'ai pû croiser ici ou là ne présentent jamais de traitement des exceptions (sauf exception )

[zais_ethael]

Pourquoi ce chapitre est t'il systématiquement (ou casi-systématiquement) passé à la trappe lors d'une formation c++ ?

Je les ai vu pendant mes cours moi, ainsi que dans tous les bouquins qu'il m'arrive de feuilleter quand je passe dans un rayon informatique. Le vrai problème est que la plupart des profs et des livres utilisent l'approche ancestrale de l'apprentissage du C++: voir un à un les éléments du langages et supposer que ça suffira pour savoir écrire des programmes. Cela peut suffire dans certains langages, car beaucoup encouragent un certain style de programmation qui doit normalement être assimilé automatiquement petit à petit. En C++ c'est très loin d'être le cas, une formation complète devrait contenir pas plus de un tiers de syntaxe et le reste consacré au coding-style tellement ce langage peut être piège et peu intuitif. Les exceptions en sont l'un des plus tristes exemples, c'est tout le coding-style qui doit être adapté pour fournir du code exception-safe. De fait il est encore préférable pour un débutant à qui on a jamais fait remarquer les 1001 façons de rendre un code instable de ne pas utiliser les exceptions jusqu'à ce qu'il ait appris la démarche correcte.

[JolyLoic]

Une des raisons principales est qu'on ne ma jamais appris à les utiliser au cours de mon cursus (universitaire).

Je donne un cours de POO/C++ assez court par rapports aux vastes sujets à traiter (2j répartis sur 4 séances). Et pourtant même dans ces contraintes de temps strictes, je parle des exceptions, ainsi que de quelques points qui vont avec (RAII, techniques de libérations déterministes de ressources dans d'autres langages, exceptions/code d'erreur, niveaux d'exception safety, notion de transaction).

Le problème des exceptions pour l'enseignement, c'est qu'on peut les ignorer dans ce cadre sans que ça ne saute trop vite aux yeux des étudiants. D'où une tendance à les repousser à la fin, quand les autres sujets, plus visibles, seront déjà un peu maîtrisés, et finalement à ne pas faire si on est à la bourre . Une autre difficulté est qu'elles demandent aussi une certaine taille de code pour avoir de l'intérêt (mais c'est aussi un problème de la POO).