Discussion :

[Clad3]

Bonjour à tous.

Je suis entrain de me poser certaines questions concernant la manière de concevoir une application propre et gérant au mieux les erreurs.

Pour le moment je ne fais rien d'autre que de logger l'erreur détecter ... ca peut etre utile mais bien évidement ca ne corrige en rien le problème et ca laisse un programme pouvant planter ou se comporter de maière imprévu.

Je n'ai jamais implémenter le système d'exeption, jai souvent lu des articles dessus, mais allez savoir pourquoi ca ne m'enballe pas des masses. Idem pour des paramètre de retours aux fonctions, qui résolvent certains problème, mais pas tous,et je trouve l'idée de devoir tester les retour dans l'objet apellant peu élégante.
Bref je n'ai pas encore la solution miracle, le but étant d'avoir un programme robuste, face a toute situation ... s'arrêtant si besoin est, mais ne plantant jamais sauvagement .

Je suis preneur de vos conseils et avis sur la question !

Dans le même cadre :
J'ai pas mal de fonction d'ajout / de délétion / de recherche d'élément dans un conteneur d'une classe. Dans chaqune de ces fonctions, je test au minimum si lo'bjet a supprimer existe.
Je me demande si il ne serait pas mieux de supprimer totalement ces test set de laisser la logique cette fois-ci dans l'objet qui se sert du conteneur de cette classe ... j'hésite.

[Luc Hermitte]

Il est difficile de donner une réponse définitive à ces questions.
Cela dépend tellement du contexte.

Si ça peut aider,
- J'utilise les assertions pour intercepter les erreurs de programmation -- quand la fonction interne de suppression pointe sur une donnée non contenue

- Les exceptions pour les erreurs liées au contexte d'exécution -- quand la fonction publique de suppression ne trouve pas d'élément qui corresponde à ce que l'on veut supprimer (on peut avoir plusieurs fonctions publiques de suppression qui font toutes appel à une fonction de recherche différente, puis à une même et unique fonction interne de suppression)

- Une simple trace + abandon du traitement courant pour les cas où une rupture de pré-condition n'est pas si tragique -- p.ex. si une des données contenue dans la télémétrie reçue est corrompue, j'ignore la donnée, mais continue malgrè tout.

- et parfois des fonctions qui renvoient des booléens (et autres rapports d'exécution)


Quant aux exceptions, avec un peu de RAII, ce n'est pas si compliqué. On peut alors plus facilement se concentrer sur le métier qui nous dira ce que l'on peut traiter et quand. Et sans avoir des codes spaghettis inmaintenables qui testent tous les appels de fonctions.


Dans les lectures, on peu considérer les articles de Matthew Wilson sur artima. Le chapitre de son bouquin Imperfect C++ qui traite de la question a de grandes similitudes avec ses articles. C'est chez Addisson-Wesley, comme d'hab'.

De la lecture.
http://www.developpez.net/forums/sho...41#post1677341