Reprise du message précédent :

+1
Il m'a montré la voie, merci Taz

 
Les tenebres se sont déchirés, la lumiere est apparue. Les aveugles se sont mis a voir, et les paralysé a se déplacer. Il touchait le code des plus manants sans honte si gene, et de ses propres main les modelaient pour que jaillisse la Beauté.
"Vade Retro, C coditas" tonna t'il d'une voix forte, et on vit des nuées obscures sortir du sol, comme des milliers d'insectes bourdonnant et grouillant s'elever vers le ciel. "Vade Retro" repeta t-il  en frappant le sol de son baton, provoquant le tonerre. Et les nuées de Cécodus, comme prise d'une immense frayeur, s'envolerent d'un meme mouvement frenetique de peur pour le lointain, et nul ne les revit jamais.
 

pareil, yavait beaucoup de merde dans ce que j'ai appris à l'école et je suis content d'être passé par ici pour me rendre compte que c'était pas tout à fait ça, donc merci

 
(drapeau)

pareil, dommage que ma boite m'ait viré, parce que mon C++ s'améliorait largement depuis quelques temps, à force de lire les remarques de Taz j'avais fini par me dire que ça ne pouvait pas être inutile

ultra ptdr
merci à tous

Si on revenait aux exceptions?
Car, les utiliser de manière robuste dans l'écriture de tout un logiciel, n'est pas une affaire si évidente qu'il n'y parait.
Et mal utilisées, c'est pire qu'autre chose   .
 
Qu'elles sont les grandes règles que vous vous définissez pour leur utilisation?
 
On peut cela dit, s'en passer (exemple: KDE, qui a été entièrement écrit en C++ en se passant des exceptions).
 
EDIT: Longue vie à ce topic, j'espère et bravo Taz pour l'initiative!  

en parlant de ca :  
 
Admettons qu'on aie besoin d'une entrée ayant comme contrainte d'intégrité d'etre positive et inférieure à 10...
 
Vous privilégiez quoi :  
- une boucle while ((x<0) & (x>10)) do
- une exception qui va relancer la méthode ?

une exception doit rester exceptionnelle. bon pour le cas d'un int, c'est un peu limite, mais je préfèrais quand même une exception à un code retour. mais en fait je comprends pas ton cas. une exception n'est pas une erreur
 
 
while(cin >> i && (i>10 || i<-10)) ?

 
Une exception ne doit être lancée qu'en cas d'un évènement qui ne doit pas survenir dans un cas "courant" (d'ou le terme exception, hein!   ).
L'utiliser dans d'autres cas est à mon sens une grave erreur, et un risque de complication inutile du code.
 
Bon par contre, si théoriquement, x doit toujours être égale ou inférieur à 10 et positif (d'ailleurs x>10 && x<10    ), et que tu te retrouves un jour avec une valeur différente (lecture d'un fichier corrompue, erreur de saisie etc), il faut étudier si, dans ce cas, l'exception est adapté ou non.
 
Souvent, cela vient d'un bug dans le code; donc il suffit souvent de faire des tests unitaires un peu partout dans ton code avec des assert (par exemple, tu controles la validité des paramètres de fonction dans chaque fonction, en tête).
 
Bref, je pense que j'utiliserai le while, même si je ne vois pas bien le contexte de ton exemple!

"de base", les exceptions ne sont pas là pour vérifier une entrée utilisateur. Mais dans le cadre de la vérification d'entrée utilisateur, on peut trouver des exception, mais de façon secondaire.
 
c'est assez fin comme point.
 
Les méthodes qui parlent d'entrée utilisateur, n'auront pas le droit de lever une exception si l'entrée est erronée, on considère çq comme normal qu'un utilisateur se trompe, mais, une fonction de parsing de caractères peut lever une exception (si elle n'est pas vouée à l'échec, comme par exemple une fonction pour convertir une chaine en nombre), elle ne sait pas qu'elle traite quelquechose de l'utilisateur, il faut donc attraper l'exception, et la convertir en quelquechose de "normal".

Où places-tu la frontière entre exception et assertion ?

python

 
tu disais ?

C malin de nous parler de python dans un topic C++ quand meme

La gestion des erreurs, restera de toute manière, un des points le plus complexe.
Il faut, dans l'équipe de développement, des méthodes strictes sur la manière de gérer les erreurs dans les diverses parties du logiciel. Ceci afin:
* d'Eviter d'avoir des messages d'erreurs inadapté pour une erreur donnée
* D'avoir des messages d'erreur redondant: "Le fichier ne peut pas être ouvert, car le fichier ne peut pas être ouvert"  Très util, comme message. Mais pourtant, on peut facilement arriver à ce genre de problème.
* Eviter que la gestion des erreurs ne devienne un cauchemard
* Eviter d'avoir 15 boite de dialogue qui s'ouvrent quand une erreur survient.
* ...
 
Dans ma précedente société, on a considérablement amélioré la consistance des messags d'erreur, leur qualité et leur pertinance (et même la stabilité du soft), en faisant un petit effort pour se donner des règles précise de codage à ce niveau.
 
Bref, toujours pensé aux méthodes que l'on va utiliser avant de commencer à coder un logiciel.

ok...

toutes façons, je pensais pas « venez parler de C ou de C++ » mais je voyais plutot un appel à sujet « comment on se sert de longjmp », « comment on fait un itérateur », etc

 
Une assertion ne sert qu'au debug, pour t'assurer que ton code est correcte, ou pour te prévenir plus rapidement si ton code possède un bug (on peut gagner un temps fou, en plaçant des assert judicieux un peu partout, en évitant par exemple la propagation de paramètres érronnées, ou de données corrompues).
 
Il ne faut bien évidemment (sauf cas exceptionnel, mais sans exception!   ), utiliser un assert (ou un VERIFY MFC) pour controler la valeur de retour d'une fonction, si une erreur de cette fonction peut survenir une fois le logiciel déploiyé.
Les assert ne marchent qu'en debug, et ne sont la que pour ça!
 
L'assertion est pour permettre à ton soft de réagir correctement en situation réèlle quand il rencontre une situation inatendue.

ouaa, il existe donc des langages dans le monde qui mappent les assertions sur des exceptions ? spaaaaavréééééééé !
 
 
 
Juste pour ceux qui ne le savaient pas, le règle d'or est qu'on ne rattrappe _jammais_ une assertion pour autre chose que pour l'afficher. Et surtout pas pour continuer silencieusement.
 
Mais la différence est sémantique, une exception est un cas rare d'erreur prévu, une assertion est un bug. Bien entendu, une exception qu'on a pas prévue est aussi un bug (sauf dans le cas où on suppose que l'utilisateur sait lire une exception, particulièrement dans le domaine scientifique).

 
en Delphi ça marche aussi

-------------> recentrage du sujet <-------------

 
tu peux parler de python mais quand je parle de Delphi c'est pas bon
 

ça sert en test. Ceci-dit, un certain nombre de projets sont livrés avec les assertions, la présence d'un bug étant pouvant être dramatique (en particulier pour les gros projet avec BDD, un bug pouvant polluer la BDD, ou encore quand la sécurité des personnes est en jeu). C'est dans ce cas que mapper les assertions sur les exceptions est pratique.

Heu si vous faites la liste, vous avez pas fini les cocos.
 
Par contre, montrer ce genre de conneries à des débutants, je suis pas sûr que ce soit très fin.

je ferme les yeux
 
de tt façon je sais même pas ce que c'est une assertion en prog...c faire le forcing d'une valeur apparement non ?

 
Non c'est verifier une condition et exploser si la condition est fausse

je fermais juste la )

une petite chose dont j'aimerais bien parler ... ce n'est pas vraiment une question, c'est plutot un tutorial (peut-etre idiot ...)
 
serait-ce possible de donner des exemples documentés de l'implémentation de stream ?
 
j'ai regardé l'implémentation des fstream ou des stringstream dans mes lib mais j'ai enormement de mal a relire ...
 
puis chez boost je n'est que vu null_stream qui n'est pas d'un interet magnifique

euh, ouaip, mais ça va être vraiment très long, y a des bouquins entiers concernant cette partie de STL... et l'implémentation est assez spécifique, en comprendre l'interface (et les streambuf) serait déjà pas mal

bin p-e un tuto sur la compréhension (en profondeur) de l'interface alors, par exemple a quoi sert une streambuf ? me semble avoir compris que c'est le buffer a partir duquel sont lu ou ecrit les flux de données, mais tout cela me parait encore flou ...

ok, bah j'y réfléchirais, mais ça sera ètre progressif. je repartirais de la copie de fichier que j'ai montré y a quelques jours et je développerais un peu : on bricolera un petit istreambuf  sur le concept source-puit, genre un streambuf rot13

bien, super merci par avance

Sinon, pour trouver ces renseignements, faut aller voir sur l'excellent bouquin en HTML "Thinking in C++" :
 
http://www.mindview.net/Books/TICP [...] CPP2e.html

c une bete eckel qd même...

 
eckel bete cet eckel

je ne te la fais pas dire.

Et sinon, y'a aussi: "Mieux Programmer en C++" chez Eyrolles; c'est pas pour faire de la pub, j'ai pas d'actions chez Eyrolles, mais c'est vraiment un petit bouquin intéressant. On se demande si on est développeur pro quand on le lit la 1ère fois. La honte...  

 
Moi non

 
 
Absolument. Mon expérience rejoint la tienne sur ce sujet : dans un projet industriel un taant soit peu sérieux, la gestion d'erreur DOIT faire partie de la conception. Si un plan de conception ne se penche pas sur la gestion des erreurs (exceptions, traces, signaux, etc), on peut dire que le travail est incomplet, voire faux, car sur certains systèmes, la gestion d'erreurs peut amener à revoir complètement la gestion des messages, qui est toujours un point délicat.
 
Après, le choix d'utiliser des valeurs de retour ou des exceptions est à la discrétion du chef technique. D'un coté, les valeurs de retour doivent être toutes testées, ce qui fait une surcharge de travail absolument considérable, sans parler de l'impact sur les performances, de l'autre, les exceptions sont parfois délicates à utiliser et nécessitent un apprentissage et une vision plus globale du système par les développeurs, vision qu'ils n'ont pas toujours dans un gros système. Personnellement, ayant eu à développer avec les deux systèmes, je préfère de loin les exceptions pour une raison : la paresse du développeur. Certaines valeurs de retour sont souvent ignorées, et c'est pratiquement ce qu'il y a de pire. J'ai vu du code où lorsque des valeurs passées en entrée d'une fonction étaient incorrectes, (un pointeur nul par ex.), la fonction ne faisait rien d'autre qu'un return; ne signalant même pas qu'il y avait une erreur.  
Quand cette pratique est généralisée, le soft non seulement ne marche pas, mais il devient infernal à déboguer car l'endroit où il plante est tellement éloigné de la cause de l'erreur que tracer l'erreur à la source devient une véritable gageure.
 
Quelque soit le choix, l'erreur à ne pas commettre est d'utiliser les deux systèmes à la fois : ça doit être une règle de développement et tout le monde doit s'y tenir. L'utilisation des valeurs de retour ET des exceptions  à la discrétion du développeur est la garantie d'un code spaghetti et peu robuste dans les cas exceptionnels. J'ai vu récemment un code où quand une fonction levait une exception, le catch mettait un booléen à false, et un peu plus loin, la valeur du booléen était testée pour lever une autre exception...
 
En ce qui concerne les exceptions, mon avis est qu'il faut se tenir à ce pourquoi ils ont été créés : gérer les cas d'erreur. Utiliser les exceptions pour le contrôle de flux dans le cas général est amha une très mauvaise idée en général, et fort peu pratique avec le debogueur, qui s'arrête à chaque fois dans le cas autoroute.
 
Enfin, en ce qui concerne les assertions, sujet sur lequel chacun a sa petite idée. La mienne est que les assertions et les exceptions n'ont pas la même utilité et que les deux doivent être utilisés simultanément. Simplement, les assertions ne partent pas chez le client, ils ne servent qu'en interne à l'équipe de dev, au débogage (systématiquement en pré/post conditions, par ex.). Par conséquent, ils ne peuvent remplacer les exceptions en cas d'erreur. D'un autre coté, on peut en mettre un peu partout dans le code, même à l'intérieur des boucles.

 
J'ai l'habitude d'en mettre partout des assert, pour controler la validité de paramètres divers, qui doivent, et c'est ce qu'il faut bien comprendre, forcemment être bon dans la release du logiciel, peu importe la situation.
En d'autre terme, si ces paramètres ne sont pas correcte, c'est qu'il y a un bug dans le logiciel; ce n'est pas une erreur de saisie de l'utilisateur, ou un fichier corrompu ou quelque chose d'autre qui ne doit pas être controlé par un assert mais par exeception ou code de retour.
 
Avec cette habitude, on est plus tranquil quand on doit apporter des modifications au logiciel. Si une fois modifié, on n'a aucun assert quand on est en debug, c'est qu'il y a de fortes chances (plus ou moins fortes suivant la pertinance des tests assert) que les modifications n'ont pas eu d'effet de bord.
Ces méthodes m'ont déjà fait gagner un temps fou, même si 99% des assert que j'ai mis ne m'ont jamais servi.