Discussion :

[LittleWhite]

Bonjour à tous,

Lorsqu'une erreur se produit dans une fonction, un développeur C++ a deux solutions : il peut soit retourner une valeur indiquant une erreur (par exemple avec return false; ou return ERROR_CODE;), soit lancer une exception. Mais quelle est la meilleure approche ?
Dans cet article, Aaron Lahman apporte des éléments de réponse à cette question cruciale en regardant les différences en terme de lisibilité et de sécurité du code.

Retour de fonctions ou exceptions ?

Quand vous écrivez une fonction, comment traitez-vous les erreurs ?
Quand vous appeler une fonction, faites vous systématiquement la vérification des erreurs ?

Bonne lecture.

[Drannor]

J'ai beaucoup aimé cet article surtout que le code sur lequel je bosse au quotidien ressemble exactement à ça. Des if dans tous les sens pour tester les HResults que renvoient de veilles fonction MFC / COM.

Par contre je trouve que la solution finale n'est pas terrible dans le sens où même si il n'y aucune fuite mémoire grâce à l'utilisation des shared_ptr, on a aussi aucune information sur quelle est erreur et pourquoi la fonction échoue.

Je suis plus de l'avis de Bjarne Stroustrup qui parle de la différence entre erreur et exception dans "Le Langage C++" avec en gros cette distinction :

- Une erreur c'est quelque chose de prévu algorithmiquement qui échoue (c'est liée intrinsèquement au code qui a été écrit)

- Une exception quelque chose de non prévisible et qui dépend que très peu du code écrit (exemple : plus de mémoire sur la machine )

[oodini]

J'ai beaucoup aimé cet article surtout que le code sur lequel je bosse au quotidien ressemble exactement à ça. Des if dans tous les sens

Comme sur le projet où je bosse.

- Une erreur c'est quelque chose de prévu algorithmiquement qui échoue (c'est liée intrinsèquement au code qui a été écrit)
- Une exception quelque chose de non prévisible et qui dépend que très peu du code écrit (exemple : plus de mémoire sur la machine )

Dans ce cas, j'ai toujours des if dans tous les sens.
Je trouve cette distinction trop restrictive.
Bien souvent, par exemple, la gestion d'une valeur de retour par l'appelant ne consiste qu'en un message de log et en un return false. Dans ces cas là, je trouve que les exceptions sont bien plus pertinentes.

[Klaim]

[meta]

Quand vous écrivez une fonction, comment traitez-vous les erreurs ?
Quand vous appeler une fonction, faites vous systématiquement la vérification des erreurs ?

Comment peut-on répondre a des question dont la réponse est toujours "ça dépends"?


Ce ne sont pas de bonnes questions. C'est comme nous demander si on utilise goto ou pas. La plupart du temps non, si ya un vrai besoin oui mais c'est rare. "ca depends".


Sincerement je ne vois pas bien l'interet de ces questions ajoutés aux articles. Le texte lui mêem souleve déjà pas mal de questions qui sont bien plus intéréssantes. Est-ce que c'est une tentative de faire réagir du monde?

[/meta]

[Bousk]

- Une erreur c'est quelque chose de prévu algorithmiquement qui échoue (c'est liée intrinsèquement au code qui a été écrit)

- Une exception quelque chose de non prévisible et qui dépend que très peu du code écrit (exemple : plus de mémoire sur la machine )

Je suis entièrement d'accord avec cette vision.
Dans mes codes, je n'utilise que très rarement les exceptions (pour ne pas dire jamais), je leur préfère les code erreurs.
Je teste le retour de la fonction, si elle en a un.

[Luc Hermitte]

Par contre je trouve que la solution finale n'est pas terrible dans le sens où même si il n'y aucune fuite mémoire grâce à l'utilisation des shared_ptr, on a aussi aucune information sur quelle est erreur et pourquoi la fonction échoue.

C'est un détail. C'est à nous d'utiliser le bon type d'exception (quand on favorise la multiplication des types d'exception), et/ou de compléter le message d'erreur renvoyé. Rien n'empêche non plus de faire remonter un code d'erreur via une exception.
C'est vraiment un détail.

Je suis plus de l'avis de Bjarne Stroustrup qui parle de la différence entre erreur et exception dans "Le Langage C++" avec en gros cette distinction :
- Une erreur c'est quelque chose de prévu algorithmiquement qui échoue (c'est liée intrinsèquement au code qui a été écrit)
- Une exception quelque chose de non prévisible et qui dépend que très peu du code écrit (exemple : plus de mémoire sur la machine )

C'est la différence entre une erreur de programmation, et un soucis dans le contexte de l'exécution. Dans le premier cas, les assertions sont notre meilleur ami (on a un article sur les assertions dans le pipeline ?), dans le second cas il s'agit des exceptions ou du RCH (qui sont au fond interchangeables)

[oodini]

Sauf que le gars qui teste derrière toi n'a peut-être pas envie que tu fasses un assert, et préférerais continuer l'exécution tout en te reportant en parallèle le message d'erreur que el programme lui a sorti.

Quand tu tapes un assert après 3h30 de calculs, tu n'es en général pas très jouasse.

[Luc Hermitte]

C'est sûr qu'il vaut mieux laisser passer et faire semblant que ça marche et à la place renvoyer silencieusement des résultats aberrants.

De plus, qu'un calcul s'arrête sur assertion ou sur exception, cela ne change rien -> il ne sera jamais arrivé au bout.

De plus, une assertion, ce n'est pas pour la production. C'est pour la phase de test et développement : pour chopper ... les erreurs de programmation.

Bref, je ressors deux liens sur le sujet:
- http://www.developpez.net/forums/d24...stion-erreurs/
- http://www.developpez.net/forums/d87...pp/#post810104

[gbdivers]

[meta]



Comment peut-on répondre a des question dont la réponse est toujours "ça dépends"?


Ce ne sont pas de bonnes questions. C'est comme nous demander si on utilise goto ou pas. La plupart du temps non, si ya un vrai besoin oui mais c'est rare. "ca depends".


Sincerement je ne vois pas bien l'interet de ces questions ajoutés aux articles. Le texte lui mêem souleve déjà pas mal de questions qui sont bien plus intéréssantes. Est-ce que c'est une tentative de faire réagir du monde?

[/meta]

Je t'en prie. Soulève ces questions et je me ferais une joie de les mettre dans le premier post. Merci

[oodini]

C'est sûr qu'il vaut mieux laisser passer et faire semblant que ça marche et à la place renvoyer silencieusement des résultats aberrants.

L'alternative est faire des logs. Il n'est pas question de faire semblant que ça marche.

De plus, qu'un calcul s'arrête sur assertion ou sur exception, cela ne change rien -> il ne sera jamais arrivé au bout.

Je n'ai pas dit que le problème arrivait pendant le calcul, mais après le calcul.
Avec une assertion, l'exécution s'arrête.
Avec une exception, tu peux essayer de rattraper le coup. Ou même sans rattraper le coup, le gérer, pour permettre l'exécution de la suite du traitement qui ne repose pas sur le résultat de ce qui a foiré.
A l'issue du programme, tu as un jeu de données; tu sais que l'une d'elle est fausse. Bon. Mais les autres, déterminées postérieurement, peuvent être totalement indépendantes, et bonnes. Si toutefois on leur a laissé une chance d'être calculées.

De plus, une assertion, ce n'est pas pour la production. C'est pour la phase de test et développement : pour chopper ... les erreurs de programmation.

C'est bien pour ça que je parlais de tests. Et le testeur n'a pas forcément envie que le programme s'arrête.

Si je fais mes courses chez Ooshop, je n'ai pas envie que mon panier soit vidé parce que le site rencontre un bug dès que je demande une boîte de petits pois.

[Luc Hermitte]

a- C'est bien pour ça que je parlais de tests. Et le testeur n'a pas forcément envie que le programme s'arrête.

b- Si je fais mes courses chez Ooshop, je n'ai pas envie que mon panier soit vidé parce que le site rencontre un bug dès que je demande une boîte de petits pois.

a- Le testeur est là pour aider le développeur à corriger le programme.
S'il y a une erreur, le développeur attend un coredump à analyser.
Et pas un rapport souvent bâclé dans lequel il va manquer la moitié des infos. Le log peut être un complément -- EDIT: notamment pour la partie historique.
Et puis franchement, si à la phase de test on n'a pas les résultats finaux, mais un rapport qui nous permettra de corriger un erreur de programmation, je ne vois pas où est le soucis.

b- Et quand tu fais tes courses, tu n'es pas testeur. Le programme qui tourne doit donc avoir ses assertions désactivées. Si la phase de test a suffisamment couvert de problèmes, tu n'auras aucun soucis.


Après, rien n'empêche de doubler les assertions par de la prog défensive (qui permet de logger et continuer). Mais en phase d'élaboration -> assertions!

[therwald]

Un petit point quand même pour des exceptions: Ooshop n'a peut-être pas envie qu'un check qui n'est fait qu'en dev permette au client que tu es d'ajouter 25 tonnes de petits pois à son panier pour 0,10€... (je grossis volontairement le trait) => parfois en cas d'erreur il faut savoir planter le process en cours...et perso je trouve que les exceptions font ça très bien

[David Fleury]

Mais en phase d'élaboration -> assertions!

Pourquoi ne pas juste mettre des bons TU au lieu de "pourrir" le code d'assert ? J'ai pas souvent trouvé de cas où un assert était plus intéressant qu'un TU.
J'avoue, je suis pas un fan des asserts (code dev != code prod), mais plutôt du TU + programmation défensive.

Sinon, dans l'exemple final, pourquoi déclarer en début de fonction les shared_ptr au lieu de le faire quand ils sont utilisés (et peuvent être initialisé).
Est-ce une nouvelle mode ?

Dommage que l'exemple "ancien" en C++, ne soit pas très joli (à mon sens).
Peut être qu'un simple auto_ptr (utilisé en scope_ptr), et il manque peut être un icon = 0 dans le catch, pour l'appelant que va sûrement tester retour.

[Luc Hermitte]

L'avantage des assertions sur toutes les autres techniques, c'est de pouvoir disposer d'un snapshot exact de l'état du programme au moment où l'on détecte une donnée dans un état aberrant/contraire à ce qui était attendu par les développeurs, histoire de pouvoir investiguer tranquillement dans un outil dédié : le débuggueur.

Cela n'empêche pas d'avoir des TU. Bien au contraire. Par contre, le TU seul ne fournit pas un fichier core prêt à être analysé.

Quant à la programmation défensive, je tends à y être opposé. Cela masque plus les problèmes que cela ne les résout. Les dév tendent déjà à ignorer les situations exceptionnelles (qui viennent de codes de retour), la prog défensive en rajoute une couche en absorbant les anormalités.
EDIT: sans parler qu'en cas d'erreur de programmation, pouvoir revenir à un état stable est tout sauf trivial, et quel est l'intérêt quand justement la prochaine étape logique (en phase de dév & test) est de corriger le bug (ou de revoir la conception/contrat du morceau de code en échec) ?

Bon, maintenant, j'ai rarement vu appliqué de la prog défensive avec exceptions. Je tends à penser que l'effet de bord pervers d'ignorer les problèmes perdure, mais je peux me tromper.


Pour ce qui est de l'exemple, ici on ne fait que traduire l'exemple de l'auteur. Mais je suis d'accord avec toi, son exemple est contraire au RAII historique (acquisition on initialization) et les bonnes pratiques de manière générale.

[therwald]

Quant à la programmation défensive, je tends à y être opposé. Cela masque plus les problèmes que cela ne les résout. Les dév tendent déjà à ignorer les situations exceptionnelles (qui viennent de codes de retour), la prog défensive en rajoute une couche en absorbant les anormalités.
EDIT: sans parler qu'en cas d'erreur de programmation, pouvoir revenir à un état stable est tout sauf trivial, et quel est l'intérêt quand justement la prochaine étape logique (en phase de dév & test) est de corriger le bug (ou de revoir la conception/contrat du morceau de code en échec) ?

Le type de programmation défensive dont tu parles c'est juste pour les environnements embarqués où l'arrêt total du process est trop couteux ("life critical applications" comme dit l'ami Billou dans la doc qui dit qu'on ne doit pas utiliser windows quand des vies sont en jeu...)
Mais dans d'autres cas je suis pour un type de programmation défensive qui consiste à définir les bornes du domaine de définition des paramètres d'appel, et renvoyer une exception si on en sort. Dans le cas par exemple d'application business où le masquage d'un bug peut avoir pour effet de vriller le précieux contenu d'une base de données c'est mieux que de faire le saut de la foi en mode "ils n'ont cas programmer leur appel correctement ces bouseux"...
Et une exception de ce type ne masque pas les erreurs du code appelant, au contraire...

[David Fleury]

Par contre, le TU seul ne fournit pas un fichier core prêt à être analysé.

Non, vu qu'ils sont censés tous passés.
Par contre, pour avoir un core, j'active le core, et en cas de plantage, je sais où je suis, et mon état. pas besoin d'assert pour ça.

Dans mon projet actuel, on peut revenir facilement à un état stable et le client ne veut surtout pas avoir de trou dans le service. On préfère donc des logs clairs afin de voir ce qui c'est passé plutôt qu'une interruption de service.

Au pire, je n'utiliserais pas assert car la fin du programme est obligatoire, alors qu'une macro ASSERT lançant une exception pourrait permettre de choisir d'attraper ou non l'exception selon la criticité de la section de code ou du programme.

Mais c'est toujours intéressant de voir les pratiques des uns et des autres.
(le pire étant que j'ai vu des assert ayant des effets de bord)

[alex_vino]

Dommage que le code ne soit pas de l'algorithmie

Sinon bon article, j'avais lu un bouquin a ce sujet et c'et intéressant.

[koala01]

Salut,

Pourquoi ne pas juste mettre des bons TU au lieu de "pourrir" le code d'assert ? J'ai pas souvent trouvé de cas où un assert était plus intéressant qu'un TU.
J'avoue, je suis pas un fan des asserts (code dev != code prod), mais plutôt du TU + programmation défensive.

Sinon, dans l'exemple final, pourquoi déclarer en début de fonction les shared_ptr au lieu de le faire quand ils sont utilisés (et peuvent être initialisé).
Est-ce une nouvelle mode ?

Dommage que l'exemple "ancien" en C++, ne soit pas très joli (à mon sens).
Peut être qu'un simple auto_ptr (utilisé en scope_ptr), et il manque peut être un icon = 0 dans le catch, pour l'appelant que va sûrement tester retour.

Les gros problèmes auxquels je suis confronté tous les jours (je parle d'un projet fourni de plus de deux mille tests unitaires et pour lequel il y a en moyenne deux à trois assertions par fonctions, c'est tout dire ), c'est que:

1 - Le tests unitaires ne valent que... pour les scénarios que l'on a déjà identifiés comme posant potentiellement problème...

Il est très utile de se dire que tous les tests unitaires passent sans problème, mais il faut garder en tete que, si c'est le cas, c'est peut etre simplement parce que l'on n'a pas encore trouvé le scénario qui prendra le programme en défaut

Après, vient la vérification de cas d'utilisation "classiques" du moins, de ceux que l'on a pu identifier ), et on remarque déjà qu'il arrive que, malgré tous les tests unitaires que l'on peut avoir, certains cas ont pu "passer entre les mailles du filet" ( re ) .

Et, bien sur, après, il y a encore toutes les utilisations que l'on n'a pas forcément prévues mais que l'utilisateur final peut décider de faire ( re re )

2 - Les assertions, c'est très bien, mais elles ne fonctionnent... qu'en mode debug

Le problème, c'est que, lorsque l'on se repose trop sur les assertions, on en arrive aisément à ne pas faire les tests "de cohérence" qui pourraient, justement, gérer le cas des assertions...

Il y a peu encore (je parle encore d'expérience), un collègue a remarqué que l'on faisait un erase sur un iterateur testé par assertion (il y avait l'équivalent d'un assert(iter != collection.end() ); ) sans en vérifier la validité au préalable, car, en théorie, on ne devait pas arriver à cet endroit avec un itérateur invalide...

Sauf que...

Ben voilà, dans un scénario donné (qui bien sur n'avait pas été envisagé dans les tests unitaires), on arrivait effectivement avec un itérateur invalide...

Je te laisse imaginer la suite

Au final, j'en arriverais bien volontiers à la conclusion que:

Oui, bien sur, les tests unitaires sont particulièrement utiles (essentiellement pour éviter les régressions)

Oui, bien sur, les assertions sont aussi particulièrement utiles (pour avoir une vue "instantanée" du problème)

Mais tout cela ne vaut que "pour la première partie" de la durée de vie du projet sur lequel on travaille

Après le dev et le test (qu'il soit automatisé ou manuel, ou meme les deux ) il y a l'utilisation réelle, et c'est finalement à ce moment là qu'apparaitront bien des problèmes.

A ce moment là, on apprécie vraiment les exceptions, surtout si chaque problème est susceptible de lancer une exception particulière.

Si le travail est bien fait, il n'est pas exclu qu'une trace du problème soit loguée "quelque part", ce qui pourra déjà apporter quelques éclaircissements.

De plus, il est souvent préférable de faire "planter proprement" le programme, plutot que de le laisser tourner avec des données corrompues.

Or, les exceptions permettent justement les deux comportements intéressants, ce qui n'est pas forcément le cas des retours d'erreurs, car, si on ne teste pas l'ensemble des codes d'erreur, elle peut très facilement "passer inaperçue"

[therwald]

De plus, il est souvent préférable de faire "planter proprement" le programme, plutot que de le laisser tourner avec des données corrompues.

Or, les exceptions permettent justement les deux comportements intéressants, ce qui n'est pas forcément le cas des retours d'erreurs, car, si on ne teste pas l'ensemble des codes d'erreur, elle peut très facilement "passer inaperçue"

++
En outre, je pense que si l'interruption totale du processus est à éviter pour des raisons de continuité de service, cela relève de la conception du modèle d'erreur, et une utilisation correcte des exceptions permet d'interrompre les traitements corrompus tout en rattrapant les erreurs au bon niveau pour permettre la continuité de service (ex: au sein disons d'un serveur web, laisser mourir le traitement d'une requête, tout en préservant le processus global pour pouvoir répondre aux requêtes suivantes).

[bugsan]

Moi j'imagine bien des mecs écrire ça :

Code :

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

1
2
3
4
5
public void checkIsNombrePair(int value) {
  if (value % 2 == 1) {
    throw new NombreImpairException();
  }
}

puis ...

Code :

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

1
2
3
4
5
6
7
try {
  checkIsNombrePair(...);
  // OK
}
catch (NombreImpairException ex) {
  // do something ...
}

En fait il y a pas mal de subtilité avec les exceptions et on a vite fait de faire n'importe quoi.
Par exemple un service qui se nomme "findQuelquechose", si il ne trouve rien, doit il retourner null, ou lancer une exception ? (c'est le cas dans les DAO, et ils retournent null ...).
En fait, cela dépend de la responsabilité que l'on confère au service. Peut/doit il prendre la décision d'interrompre le traitement ?


Par exemple une méthode "persist" qui n'a pas réussi a persister la donnée, elle doit lancer une exception. Si on souhaite la coder en mode "code retour", on peut, mais dans ce cas je la nommerais "tryPersist", car on suggère que la méthode peut échouer sans grande gravité ...