suite à un post récent j´ai dévellopé une petite bibliothèque de gestion de base de données (vous la verrez très bientôt).

Mais pour faire un code "robuste" je me suis essayé àla gestion d´erreur : sauf cas particulier, les fonctions (qui sont plutôt des instructions donc) ne renvoient jamais d´argument, mais par contre lèvent une exception en cas de problème (throw ERROR_CODE;).

J´aimerais savoir dans quelle mesure un tel code est-il opérable avec d´autre langage (C, VB ?) , d´une part, et si vous avez des conseils là dessus : est-il bien connu que la gestion des erreurs ainsi est ennuyeuse ? ou présente de gros défaut ? etc.

merci.

généralement les exceptions sont assez mal géré par les compilateurs ce qui posent parfois des problemes.
quant a la compatibilité avec d´autre langage: sous windows, je crois me rappeler que les exceptions C++ sont des exceptions "systeme" qui peuvent onc etre recuperer comme telle.
Je pense qu´en VB, les "on error" utilisent en fait des exceptions. mais ceci est une speculation

Si on parle C++, les exceptions ne passent pas sur tout les compilateurs, effectivement, car certain de respecte pas exactement le standard. Mais il faut avouer que ca ne touche pas les principales plateformes grand publique. Il y aura toujours un compilateur C++ gérant les exceptions sous PC (Win/Linux) et Mac.

Ce qui est parfois vraiment embetant avec les methodes qui renvoient des exceptions c´est que tu es bien obliger de les traitees. Personnelement, si j´ai un code qui lancer des exception, je fait un systeme permettant de [des]engager les exceptions ponctuellement. Ce qui permet d´enchenner une sequence de methode sans avoir a ce soucier du retour.

notons au passage que dans bcp d´applis on desactive completement le support des exceptions : trop couteux (rapidite + overhead ; comme les RTTI d´ailleurs, qu´on remplace joyeusement par des sytemes maisons de downcasting), compare au benefice. On preferera des systemes personnalises de gestion d´erreurs (ce qui permet au passage une certaine souplesse, output dans des logs, traitements automatises differents selon la gravite de l´erreur, etc).
Le seul truc reelement interessant des exceptions, c´est de pouvoir faire un "throw" dans un constructeur, et aborter la construction de l´objet (c´est d´ailleurs le seul moyen de le faire). Vu l´interet limite, la encore on prefere souvent s´en passer.

Vous pensez jamais qu´il y´a des gens qui n´ont pas le temps de faire achement d´études en théorie informatique qui pourraient quand même avoir envie de savoir de quoi vous parlez ?

"comme les RTTI d´ailleurs, qu´on remplace joyeusement par des sytemes maisons de downcasting"
-> C´est quoi tout ça

run time type information ... c´est assez recent je crois ... enfin , le seul truc que je connais en rapport avec ça , c´est le dynamic_cast<> ... ça permet de dire si un pointeur est du type machin ou truc par exemple ... mais bon, j´y connais pas grand chose de plus en fait

Bigloo > L´info c´est comme tout domaine un peu pointu : pour pouvoir détailler ses problèmes, il faut utiliser un jargon précis, au lieu d´un vocabulaire vague ou a rallonge pour redéfinir les concepts à chaques fois.

En outre, le personnes désirant savoir de quoi il retourne peuvent très bien effectuer une recherche sur google (avec les mots clés adéquat, "exceptions" notament dans cecas là) au lieu d´attendre que ca leur tombe tout cuit, ou demander explicitement sur le topic la signification de tel ou tel terme.

Le but de ce genre de question est avant tout la résolution d´un problème, pas un tutoriel ouvert à tous décrivant la gestion des exceptions dans le cas présent.

Je ne me suis jamais vraiment penché sur le coté performance pour ce qui concerne les exceptions, mais est ce vraiment si couteux que cela ?
D´un point de vue utilitée y´a pas photo, c´est bien plus agreable, sur et simple que les autres types de gestion d´erreur.
Le cout qu´engendre les exceptions se situe a quel niveau ? Sur les try/catch ? Sur tout appel se situant dans un try/catch ou juste sur les throw ?

De plus, sur un lib d´acces a une DB, ce sur-cout n´est il pas negligable ?

lag-it> Excellente idée, la recherche. C´est ce que je viens de faire pour le "downcasting". Je crois que te laisser faire la-dite manoeuvre te fera comprendre dans quel état d´effarement ça peut plonger un débutant.

Maintenant qu´on ne veuille pas me répondre, ok & c´est pas grave.

(Mais les RTTI ça y´est je sais, merci jejej et le "Glossaire du C++". Et tac je suis rattaqué au débat en attendant la réponse à ce qu´a dit Kouic)

(PS : désolé de t´avoir fait perdre ton temps à me répondre d´aller chercher)

J´avoue que j´ai du mal à comprendre ton attitude hostile à l´égard de la moindre remarque que l´on puisse te faire Bigloo, faut savoir être un peu ouvert à la critique, d´autant plus quand il s´agit d´une simple suggestion comme ici.

Il me semble assez légitime de rappeler qu´il est impossible à chacun de redéfinir l´ensemble des concepts dont il est question dans un topic, d´abord parce que ca prendrait 5 pages, ensuite parce que son auteur attends généralement une réponse tout aussi précise que la nature du problème qu´il détaille (dans de nombreuses situation en outre, il est impossible d´utiliser un mot autre que celui du jargon informatique. Comment traduire déréférenciation, polymorphisme etc... pour un néophyte sans tout réexpliquer?).

Sinon concernant la recherche, je répète que quelqu´un qui désire en savoir plus sur un sujet ne doit pas se priver de demander, il obtiendra très certainement pas mal de réponses et de liens de qualité sur le sujet (c´est quand même une des raisons d´être de ce forum : demander à ceux qui s´y connaissent l´information la plus pertinente concernant un sujet).

La remarque "Vous pensez jamais qu´il y´a des gens qui n´ont pas le temps de faire achement d´études en théorie informatique qui pourraient quand même avoir envie de savoir de quoi vous parlez ?" me semblait juste un petit peu déplacée, mais bon pas de quoi y voir une aggression violente pour autant.

Enfin bon je ne veux pas entrer dans un débat...

(sinon oncernant downcasting, je me suis contenté de taper le mot brut sur google et cliquer sur "j´ai de la chance" et je suis tombé sur ca :

downcasting
Doing a cast from a base class to a more specific class. The cast does not convert the object, just asserts it actually is a more specific extended object. e.g. Dalamatian d = (Dalmatian) aDog; Most people will stare blankly at you if you use the word downcast. Just use cast.

difficile d´être plus clair. Alors certes cela emploe encore des concepts propre à la programmation, mais il faut savoir ce que l´on veut et vaux aussi. On se lance pas dans la programmation d´un moteur 3d ou la compréhension du fonctionnement d´un OS quand on a que des notions de basic élémentaires...)

"me semblait juste un petit peu déplacée, mais bon pas de quoi y voir une aggression violente pour autant. "
-> C´est exact, elle n´était pas violente, pas sérieuse non plus. Je sais très bien qu´on n´est pas sur wikipédia et que vous ne pouvez pas encadrer tous les termes techniques que vous employez de [[ et ]]

"je me suis contenté de taper le mot brut sur google et cliquer sur "j´ai de la chance" et je suis tombé sur ca"
-> J´ai cherché à échapper aux documents Java mais c´est vrai que j´étais tombé sur une définition (francophone) allant dans le même sens.

La réponse de LGV va à peu près dans le sens de ce que je me demandais, à savoir si c´était performant. Faut dire, que même si ça semble logique, c´est la première fois que j´entend dire que ça coute en performance la gestion d´erreur.

Mais en fait ma question se situait plus au niveau de ce qui se fait dans la réalité. Puice que comme le dit Kouic, ce qui est embétant c´est qu´il faut traiter les exceptions. Mais a priori, quel que soit le système utilisé, il faut toujours traiter les exceptions (même si ça passe par un retour de code d´erreur), donc c´est quand même plus propre d´avoir quel que chose de centraliser que de devoir tester partout les valeures de retours.

bon, je vous montrerai incessement ce que ça donne dans ma lib.

Je peux poser une question con ? Comment se passe exactement la gestion des exceptions ?

Je connais pas le code C++ mais imaginons que ça soit un truc du genre

try:
machinchose()
except:
etc...

qu´est-ce qui arrive au moment où machinchose() foire ?

dnob, j´avais entendu que la gestion d´exception generait un equivalent de 300000 ligne de code (c´tait peut etre en C#)

Laissez tomber ma question, l´article dans wikipédia m´a fait comprendre que de toute façon j´arriverai pas à comprendre tant que j´aurai pas vu autre chose.

• • déprimé **

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1336.pdf

pages 19 et suivantes, pour les RTTI et les exceptions.

Gerer les erreurs ne coute pas forcement : dans le cas expose ici, ca ne vient que des exceptions. Bien sur, comme qqun se pose la question plus haut, tout depend du contexte : pour une application qui necessite une grande robustesse (BdD, transerts bancaires, etc.) on choisira les solutions les plus sures, sans se preoccuper des couts ; et la les exceptions seraient un tres bon choix. Dans un contexte autre, comme un jeu, le choix des exceptions est a proscrire.

Qq trucs fait usuellement dans des contextes ou la performance prime sur la robustesse:
- module de gestion d´erreur "plugable" sur le coeur du systeme. En cours dev, il sera actif, pour reperer tout comportement anormal ; dans la version finale, l´application, est sense se comporter correctement, donc on desactive quasiment toute la gestion d´erreur (dans la mesure du raisonnable pour continuer d´assurer un fonctionnement correct). On grapille donc qq ms de traitement, mais si ca crashe, ca crashe..
- des macros pour s´assurer de nombreuses preconditions (pointeurs bien inites, valeurs dans la plage, etc.) ; ces macros ne feront RIEN en mode release
- une erreur qui n´est pas critique, plutot que la traiter localement, on preferera la referencer dans un "gestionnaire d´erreur" ; qqch avec un couplage faible donc, par rapport au reste du code. Ce gestsionnaire pourra informer le programmeur en temps reel des erreurs, mais generer un log detaille, un log specifique pour un module de l´appli, etc. Bref un outil pour analyser les erreurs, pas juste tout arreter des que qqch se passe mal. De plus, une erreur non critique ne doit pas etre fatale, l´application doit se poursuivre.
- si on doit terminer l´appli en urgence (i.e. erreur critique irrecuperable), un moyen de proceder est de faire du "stack unwinding". L´idee est la suivante : quand on inite l´appli, on inite chacun des composants, mais en meme temps on laisse sur la pile les adresses du code de cleanup pour chacun des composants. Quand on veut terminer en urgence, il suffit de remonter la pile, pour terminer (a peu pres) proprement, dans toute circonstance critique. Ce n´est qu´une astuce, mais ca peut donner des idee.
- pour les RTTI, plein de trucs ne servent a rien, en general. On peut y subsituer un mecanisme minimaliste qui va se contenter de maintenir des tables de pointeurs sur interfaces, pour pouvoir faire du downcasting maison.

voila voila, qq idees en vrac..

Petite indication supplementaire par rapport aux posts de lgv: les exceptions sont le seul moyen "propre" d´aborter la construction d un objet, avec du stack poping/unwinding, bref avec un chti peu d asm, on peut le faire, mais c est un peu plus complique a coder. Tres pratique si on veut faire du code 100% relocatable sans donnees statiques.

/kUfa