Discussion :

[Invité]

Le principe de "toute erreur doit être traitée" est un bon principe pour enseigner le c++, mais dans la réalité, c'est loin d'être toujours vrai.

Je suis assez d'accord avec ça... Il y a peut être des cas où la gestion exhaustive des erreurs a un sens, mais le plus souvent, l'environnement d'une fonction garantit l'absence de certaines erreurs, ou ne les fait apparaitre qu'en cas de disfonctionnement en amont (qui doit être traité en amont).

Tester les erreurs systématiquement, tout le long de la chaine, ca rend le code bêtement illisible, sans pour autant le sécuriser. Et ca donne un peu l'impression que le programmeur est soit terrifié, soit a eu la flemme de démonter les échafaudages une fois le programme mis au point.

Quant aux exceptions, mon principal problème, ce sont les grands "try" qui essaient d'attraper "tout ce qui pourrait mal se passer". Une erreur quelconque, ce n'est pas gérable, et ces try ne servent souvent qu'à quitter l'appli sans message d'erreur. Comme gestion d'erreur, c'est très pauvre.

Idéalement, on doit être capable de spécifier les erreurs possibles, et donc de les tester au moment où elles peuvent se produire. Et dans ce contexte, les exceptions sont moins utiles. (Je ne parle pas de la mise au point: pour cela on a assert et autres échafaudages temporaires)

Francois

[gl]

Je suis assez d'accord avec ça... Il y a peut être des cas où la gestion exhaustive des erreurs a un sens, mais le plus souvent, l'environnement d'une fonction garantit l'absence de certaines erreurs, ou ne les fait apparaitre qu'en cas de dysfonctionnement en amont (qui doit être traité en amont).

Je me permet juste de rebondir sur ce point.

Je fais parti des personnes qui pense qu'effectivement toutes les erreurs doivent être traitées, ce qui ne m'empêche pas paradoxalement (enfin de prime abord) d'être tout autant d'accord avec toi.

Je pense qu'il faut commencer par définir ce qu'on entends par "traiter toutes les erreurs". Est-ce comparer l'erreur remontée (quelque soit le mécanisme utilisé) avec les différentes erreurs possibles et afficher un message d'erreur ? Certes non.

"Traiter toute les erreurs" signifie (de mon point de vue) s'être poser la question "que devons-nous faire lors de cette erreur ?" et d'avoir un programme qui réagit correctement par rapport avec la conclusion de cette réflexion.

En ce sens (et toujours de mon point de vue), tester spécifiquement toutes les erreurs et réagir en conséquence, adapter un comportement unique pour tout ce qui n'est pas OK, laisser planter le programme, ignorer une erreur car on s'est assuré préalablement qu'elle ne doit pas arriver, etc. peuvent être des façons de traiter l'erreur lorsque le choix est fait en toute connaissance de cause.

[Médinoc]

Un petit Up:
Un problème des exceptions en C++ est qu'elles n'ont pas les mêmes avantages qu'en Java et .Net.
En Java et .Net, les exceptions facilitent grandement le débogage et l'exploration de la cause de l'erreur, car elles contiennent la trace de la pile et peuvent être chaînées sans perdre les informations de l'exception d'origine.
En gros, cela contient beaucoup plus d'informations qu'un simple code d'erreur.

Cela dit, en C++ aussi les exceptions peuvent contenir plus d'informations qu'un code d'erreur seul (mais ni trace de pile ni chaînage).

Et même du côté de COM, Microsoft a vu que les codes d'erreurs ne suffisaient pas toujours: COM supporte quelques infos supplémentaires (mais pas beaucoup) avec les interfaces IErrorInfo et ISupportErrorInfo.

[3DArchi]

Salut,

Un petit Up:
Un problème des exceptions en C++ est qu'elles n'ont pas les mêmes avantages qu'en Java et .Net.
En Java et .Net, les exceptions facilitent grandement le débogage et l'exploration de la cause de l'erreur, car elles contiennent la trace de la pile et peuvent être chaînées sans perdre les informations de l'exception d'origine.
En gros, cela contient beaucoup plus d'informations qu'un simple code d'erreur.

Ceci-dit, les exceptions permettent d'abord de transporter une erreur depuis son lieu de survenue vers son bon niveau de traitement. Qu'il manque des informations de contexte comme la pile par exemple peut être embêtant en cas de debuggage (que ce soit par le développeur .... ou l'utilisateur lorsqu'il clique sur 'envoyer information...'). Mais pour un fonctionnement nominal, l'important est de pouvoir traiter l'erreur au bon endroit, non ?

[Médinoc]

En effet.

C'est aussi pour ça que je suis contre les exceptions pour les erreurs "auxquelles on s'attend". Pourquoi n'existe-t-il pas de fonction TryOpenFile() ?

[white_tentacle]

C'est aussi pour ça que je suis contre les exceptions pour les erreurs "auxquelles on s'attend". Pourquoi n'existe-t-il pas de fonction TryOpenFile() ?

Parce que comme tu fais du RAII, il ne te reste que l'exception pour indiquer un échec .

[Médinoc]

Je fais du RRIF (Resource Release Is Finalization, un bien meilleur nom pour cet idiome dont l'élément le plus important est le destructeur), mais je suis contre le "RAII systématique" à outrance, précisément pour cette raison.

[3DArchi]

Salut,

Je fais du RRIF (Resource Release Is Finalization, un bien meilleur nom pour cet idiome dont l'élément le plus important est le destructeur), mais je suis contre le "RAII systématique" à outrance, précisément pour cette raison.

Je me demande si à côté du destructeur, la politique de copie (partage ou non ou partiellement...) n'est pas toute aussi importante. RAII/RRIF finalement les big 4 sont tous aussi importants :
-> constructeur pour acquérir la ressource
-> destructeur pour la libérer
-> copy-constructreur & opérateur assignation pour la politique de copie.

[Médinoc]

Franchement, je ne vois pas l'intérêt d'acquérir la ressource spécifiquement dans le constructeur, surtout que ça te bouffe un moyen de reporter une erreur; pour moi, les exceptions restent à réserver aux erreurs exceptionnelles.

Par contre, la politique de copie (ou de refus de copie) est essentielle, je te l'accorde.

PS: Au passage, le coup du "exception uniquement" n'est pas tout-à-fait vrai: La STL ne l'utilise pas.

[white_tentacle]

Franchement, je ne vois pas l'intérêt d'acquérir la ressource spécifiquement dans le constructeur, surtout que ça te bouffe un moyen de reporter une erreur;

Ca te permet de rajouter un invariant sur ta classe. C'est pas mal de ce point de vue.

pour moi, les exceptions restent à réserver aux erreurs exceptionnelles.

Pour moi, elles sont à utiliser en cas d'impossibilité de garantir ses postconditions . Mais ce n'est pas contradictoire avec ce que tu dis.

Par contre, la politique de copie (ou de refus de copie) est essentielle, je te l'accorde.

+1.

[3DArchi]

Franchement, je ne vois pas l'intérêt d'acquérir la ressource spécifiquement dans le constructeur

Je comprends ce que tu veux dire, mais je partage l'avis de white_tentacle (invariant). C'est que je trouve assez embêtant de dire qu'une enveloppe RAII/RRIF/RICH (Resource Is Correctly Handled ) peut avoir un état 'sans ressource'. Cela amène à mon avis à des gestions particulières dans le destructeur et la politique de copie.
En fait, une enveloppe RAII ne fait pas tant l'acquisition de la ressource que son appropriation. Rien ne t'empêche d'écrire (exemple stupide, mais c'est pour illustrer - tu pourrais faire la même chose avec un handle de fichier, un lock, etc.) :

Code :

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

1
2
3
4
5
    TYPE *p = new TYPE;    
    if(p)
    {
        boost::shared_ptr<TYPE> raii_p(p);
    }

Ceci dit, on peut utiliser un shared_ptr pour le comportement que tu indiques :

Code :

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

1
2
3
4
5
6
7
boost::shared_ptr<TYPE> raii_p; // enveloppe sans ressource
 
    TYPE *p = new TYPE;
    if(p)
    {
        raii_p.reset(p); // 'init' de la ressource
    }

Ce qui pourrait s'étendre à tes propres enveloppes.

PS: Au passage, le coup du "exception uniquement" n'est pas tout-à-fait vrai: La STL ne l'utilise pas.

Je n'ai pas compris à quoi tu te réfères ? Utiliser uniquement des exceptions pour le retour d'erreur ?

[Médinoc]

Je n'ai pas compris à quoi tu te réfères ? Utiliser uniquement des exceptions pour le retour d'erreur ?

Non, mais plutôt ne pas utiliser des exceptions pour "je ne sais pas si je peux faire ça, il est même très probable que je ne puisse pas, mais si je ne peux pas pas grave, j'ai déjà prévu le coup".

Bref, les cas qui justifient l'utilisation d'un HashMap.TryGetValue() plutôt que HashMap.GetValueAndThrowIfNotFound().