Discussion :

[Kromagg]

Bonjour,

Je me posais la question suivante: dans quels cas faut-il utiliser les exceptions à la place des assertions, et inversement ?
Actuellement j'utilise les assertions pour vérifier en entrée d'une fonction/méthode que toutes les conditions sont remplies (pas de pointeur nul, pas d'index en dehors de l'intervalle requis...) et j'utilise les exceptions pour des erreurs d'exécution du genre ouverture de fichiers...

Merci

[Iradrille]

Hello,

Ça me semble une bonne utilisation.

Les exceptions sont là pour toutes les erreurs imprévisibles (exceptionnelles ?) qui ne dépendent pas du code (comme une erreur d'entrée / sortie : fichier manquant par exemple).

Pour tester les pré/post conditions des fonctions les assertions sont bien : si ça passe en debug, ça passera en release et les assert disparaissent.

[Médinoc]

Les assertions servent à tester des comportements attendus du code, tels que si l'assertion foire, c'est forcément une erreur dans le code, et non un problème extérieur (fichier manquant, etc.)
Par exemple, tester les invariants de sortie d'une fonction, avant que la fonction retourne. Si la fonction doit remplir un buffer de chaîne, on asserte que le buffer est toujours terminé par \0 à la fin. Si l'assertion échoue, ça montre un bug dans la fonction vu qu'elle ne respecte pas un invariant de sortie.

En revanche les exceptions sont pour des erreurs hors du contrôle du programmeur (ou dans le cas d'une bibliothèque, hors du contrôle de son créateur). Par exemple, un fichier indispensable manquant ou une clé requise non-trouvée dans un dictionnaire (pour un fichier ou une clé optionnels, un bête retour de valeur d'erreur peut être préférable).

Pour vérifier les paramètres d'une fonction, le choix entre exception et assertion dépend du contexte, du fait que la fonction soit publique ou interne, des traditions de la plate-forme, et de la probabilité que le respect d'une règle (genre: cet argument ne doit jamais être nul) puisse changer d'une exécution à l'autre:

• S'il y a un risque que l'erreur soit présente en Release, on utilisera forcément une exception.
• Si la fonction est interne et que son appelant est supposé avoir déjà vérifié les pré-conditions, on utilisera une assertion.
• etc.

[Luc Hermitte]

Assertions -> erreurs de programmation
Exception -> erreurs de contexte.
Utiliser les exceptions pour de l'erreur de programmation, c'est de la programmation défensive, et cela a vite fait de masquer les problèmes réels (même si cela "stabilise" le logiciel en production).

[Emmanuel Deloget]

Hello,

Ça me semble une bonne utilisation.

Les exceptions sont là pour toutes les erreurs imprévisibles (exceptionnelles ?) qui ne dépendent pas du code (comme une erreur d'entrée / sortie : fichier manquant par exemple).

Pour tester les pré/post conditions des fonctions les assertions sont bien : si ça passe en debug, ça passera en release et les assert disparaissent.

Ce n'est hélas pas suffisant. Un test de validité des pré/post-condition doit toujours s'accompagner d'un mécanisme qui renvoie une erreur à l'appelant en cas de violation - sans quoi, ton programme release risque de laisser passer certains cas que tu pourrais ne pas avoir trouvé en debug (parce que ton ensemble de données de test sera plus grand une fois ton application déployée).

Je voudrais revenir sur un point : le fait de réserver les exceptions à de erreurs exceptionnelles est débattable. De fait, c'est le seul moyen qu'on a de renvoyer une erreur dans un constructeur (quel que soit le degré d'exceptionnalité de l'erreur en question). Ensuite, le stack unwind implicite est du même ordre (en terme de pénalité sur les performances) que le stack unwind explicite lié au test d'un code d'erreur. Un des problèmes liés aux exceptions est qu'il fragilise globalement le code si on y prends pas garde, et que leur utilisation casse le flux de contrôle du programme (pouvant rendre celui-ci plus complexe à appréhender lorsqu'on débogue un problème).

Ceci dit, ces problèmes sont compensés par le fait que leur seule présence (et utilisation) permet d'affiner le sens du code.

Un exemple simple : si une fonction n'a pas besoin de renvoyer quoi que ce soit, alors sémantiquement il est plus juste de la définir avec un type de retour void. Si cette fonction peut traiter des cas d'erreur, alors l'utilisation d'exception permet de préserver sa sémantique (qui n'est plus préservée si on renvoie un code d'erreur).

[koala01]

Ce n'est hélas pas suffisant. Un test de validité des pré/post-condition doit toujours s'accompagner d'un mécanisme qui renvoie une erreur à l'appelant en cas de violation - sans quoi, ton programme release risque de laisser passer certains cas que tu pourrais ne pas avoir trouvé en debug (parce que ton ensemble de données de test sera plus grand une fois ton application déployée).

Cela a été un de mes cauchemars lors d'une précédente mission

Je voudrais revenir sur un point : le fait de réserver les exceptions à de erreurs exceptionnelles est débattable. De fait, c'est le seul moyen qu'on a de renvoyer une erreur dans un constructeur (quel que soit le degré d'exceptionnalité de l'erreur en question). Ensuite, le stack unwind implicite est du même ordre (en terme de pénalité sur les performances) que le stack unwind explicite lié au test d'un code d'erreur. Un des problèmes liés aux exceptions est qu'il fragilise globalement le code si on y prends pas garde, et que leur utilisation casse le flux de contrôle du programme (pouvant rendre celui-ci plus complexe à appréhender lorsqu'on débogue un problème).

Ceci dit, ces problèmes sont compensés par le fait que leur seule présence (et utilisation) permet d'affiner le sens du code.

Un exemple simple : si une fonction n'a pas besoin de renvoyer quoi que ce soit, alors sémantiquement il est plus juste de la définir avec un type de retour void. Si cette fonction peut traiter des cas d'erreur, alors l'utilisation d'exception permet de préserver sa sémantique (qui n'est plus préservée si on renvoie un code d'erreur).

Je suis --globalement-- d'accord avec toi.

Cependant, à force de vouloir renvoyer des codes d'erreur ou lancer des exceptions, on en arrive à une mode de programmation "défensive" qui tôt ou tard nuira très fortement aux performances globales de l'application.

Je suis donc d'accord avec Luc (et pour cause, nous avons eu l'occasion de discuter longuement du problème ) :

Les assertions devraient, systématiquement, être utilisées pour détecter le erreurs de programmation: le fait qu'une collection est vide, alors qu'elle est sensée contenir au minimum un élément, qu'un pointeur soit nul alors qu'il n'aurait pas du l'être, qu'un index dépasse la capacité d'une collection, qu'une chaine de caractères respecte un pattern donné, j'en passe et de meilleure.

Les exceptions devraient, quant à elles, être utilisées pour tout ce qui est "hors de controle" du développeur de l'application:

• une connexion réseau défaillante (parce que le serveur est "down" ou qu'un psychopathe a coupé le fil)
• un fichier inaccessible car "verrouillé" par une application tierce
• une allocation dynamique de mémoire qui échoue (c'est l'OS qui donne la mémoire dynamique )
• ...

Lorsque l'on applique une politique de test (tests unitaires, mais aussi test manuelle de scénario clairement identifiés), il est "logique" de penser que tous les cas d'assertions devraient être couverts, meme si on ne peut s'empêcher de penser que cette politique ne fait que nous démontrer que l'on n'a pas encore réussi à prendre l'application en faute

Mais, a priori, les erreurs de programmation devraient toutes avoir été corrigées avant la mise en production. Il n'y a donc aucune raison probante pour que les tests qui permettent de nous en assurer soient effectués en release

[Iradrille]

Ce n'est hélas pas suffisant. Un test de validité des pré/post-condition doit toujours s'accompagner d'un mécanisme qui renvoie une erreur à l'appelant en cas de violation - sans quoi, ton programme release risque de laisser passer certains cas que tu pourrais ne pas avoir trouvé en debug (parce que ton ensemble de données de test sera plus grand une fois ton application déployée).

J'ai du mal à voir comment : les fonctions sont appelées avec les mêmes paramètres, s'il n'y à pas d'erreur en debug, il ne peut pas y en avoir en release (sauf éventuel problème d'optimisation trop agressive mais c'est hors sujet je pense).

Si une fonction traite des données différentes en debug et release (parser des fichiers différents par exemple), alors on se retrouve dans le cas d'une erreur qui ne dépend pas du code et on utilise donc des exceptions.

Quand à savoir s'il vaut mieux utiliser des exceptions ou un code de retour, je pense (et je pense que beaucoup d'entre vous ont le même point de vue) que les exceptions sont préférables dans 90% des cas.

Mais, a priori, les erreurs de programmation devraient toutes avoir été corrigées avant la mise en production. Il n'y a donc aucune raison probante pour que les tests qui permettent de nous en assurer soient effectués en release

A part les problèmes d'optimisations trop agressives "méchant compilo, il casse tout mon code !", il ne devrait pas y en avoir besoin non. Je ne vois en tout cas pas comment une erreur peut apparaître en release SI les assert / exceptions / code de retour ont étés utilisés correctement.

Si vous avez un exemple d'erreur qui peut apparaître en release, je prend.

[koala01]

Si vous avez un exemple d'erreur qui peut apparaître en release, je prend.

Une erreur toute bête: une collection de pointeurs nu qui n'est pas correctement mise à jour après destruction d'un objet sous-jacent. On se retrouve avec une fonction

Code :

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

1
2
3
4
5
6
7
void foo(std::vector<UnType *> const & tab){
    for(auto const & it : tab){
        assert(it!=nullptr); //oupss, it ne vaut jamais nullptr
        it->doSomething(); // comportement indéfini en release si l'adresse mémoire correspondant à it a été libérée
                           // ou si it a bel et bien été remis à nullptr mais n'a pas été supprimé de la collection
    }
}

Ca devient rapidement un calvaire à déboguer, surtout quand il est difficile de définir le scénario qui a mené à cette situation

[Emmanuel Deloget]

J'ai du mal à voir comment : les fonctions sont appelées avec les mêmes paramètres, s'il n'y à pas d'erreur en debug, il ne peut pas y en avoir en release (sauf éventuel problème d'optimisation trop agressive mais c'est hors sujet je pense).

La théorie dit que c'est vrai. Mais comme la théorie dit aussi qu'elle est identique à la pratique, il y a des fois où il vaut mieux être paranoïaque

Le fait qu'aucune assertion ne soit levée en debug signifie juste que le chemin de code testé en debug est valide. Un changement dans les données initiales peut changer le flux du programme et provoquer des erreurs qui peuvent ne pas avoir été détectée en debug. D'où la nécessite de mettre les tests correspondants, afin que ces erreurs ne posent pas de problème en release.

Si une fonction traite des données différentes en debug et release (parser des fichiers différents par exemple), alors on se retrouve dans le cas d'une erreur qui ne dépend pas du code et on utilise donc des exceptions.

Ce n'est pas tellement ça. Le problème est qu'en tant que programmeur (ou testeur), on travaille nécessairement sur un ensemble de donnée plus réduit que l'ensemble des données qui seront utilisée en production. On le conçoit naturellement si on fait un programme qui est distribué à plusieurs millions d'exemplaires : il y a des chances que les utilisateurs tombent sur un cas insuffisamment testé en debug - là où un assert l'aurait détecté.

Quand à savoir s'il vaut mieux utiliser des exceptions ou un code de retour, je pense (et je pense que beaucoup d'entre vous ont le même point de vue) que les exceptions sont préférables dans 90% des cas.A part les problèmes d'optimisations trop agressives "méchant compilo, il casse tout mon code !", il ne devrait pas y en avoir besoin non. Je ne vois en tout cas pas comment une erreur peut apparaître en release SI les assert / exceptions / code de retour ont étés utilisés correctement.

Ma fois, si une erreur se produit en release, c'est qu'elle n'a pas été détecté avant, ce qui ne se produit que dans un seul cas : le jeu de test n'est pas assez important (mais dans certains cas il est impossible qu'il soit complet, ce qui signifie qu'il est nécessairement trop petit). Tous les code path ne sont pas testés ou le sont insuffisamment. A partir de là, on peut imagine tout et n'importe quoi.

Je rappelle que mon métier est de créer des bugs (les gens appellent ça des logiciels, mais soyons réalistes : existe-t-il un logiciel non trivial qui soit exempts de bug ?), ce qui a comme propriété intéressante de me donner du travail à faire par la suite.

Si vous avez un exemple d'erreur qui peut apparaître en release, je prend.

Si on part du principe que les assertions ne sont pas visibles en release, alors binutils est une source potentielle d'exemples (binutils garde les asserts en release ; si on rencontre un assert en utilisation normale, ça veut dire qu'enlever cet assert aurait provoquer un bug - quel que soit le bug en question).

Je suis récement tombé sur un bug dans binutils (dans ld en fait) en créant une toolchain de cross compilation pour ARM big endian. En compilant uboot pour certaines plateformes ARM little endian, j'ai provoqué des assertions dans ld au lieu d'avoir un message d'erreur m'indiquant que ARMEB et ARMEL ne peuvent être linké ensemble.

D'un point de vue plus générique, le fait de passer de debug en release change beaucoup de choses - certaines fonctions deviennent inline, voire intrisic, certaines macros n'ont plus le même comportement, etc. Du coup, le code testé en release est différent du code testé en debug (et je ne parle même pas des optimisations qui peuvent amener à un réordonnacement du code assembleur). Un assert peut tester la validité d'une valeur initialisée de manière indirecte dans un macro, la macro peut être différente en release pour des questions d'optimisation, et pouf - la valeur n'est plus initialisée de la même manière.

Les scénariis sont aussi nombreux que les bugs possibles

[koala01]

Le tout, sans oublier le cas où tu as un véritable singe qui fait du grand n'importe quoi avec son clavier et sa souris

[Iradrille]

Je n'avais pas pensé à ces points, je ne verrai plus les asserts comme "des protections ultime" contre les bugs.

[koala01]

Je n'avais pas pensé à ces points, je ne verrai plus les asserts comme "des protections ultime" contre les bugs.

Disons que, en théorie, les assertions sont des protections suffisantes contre les bugs.

Mais pour que la théorie rejoigne la pratique, il faut une politique de test efficace et suffisante avant la mise en prod

[oodini]

Si on a outil du genre Coverity, on peut se permettre d'être moins parano.

[Luc Hermitte]

Tout dépend ce que tu entends par parano. De sûr, avec clang-analyse ou l'option /analyse de VS, les assertions sont exploitées pour guider l'analyse statique de code.

[ManusDei]

J'ai du mal à voir comment : les fonctions sont appelées avec les mêmes paramètres, s'il n'y à pas d'erreur en debug, il ne peut pas y en avoir en release (sauf éventuel problème d'optimisation trop agressive mais c'est hors sujet je pense).

Si une fonction traite des données différentes en debug et release (parser des fichiers différents par exemple), alors on se retrouve dans le cas d'une erreur qui ne dépend pas du code et on utilise donc des exceptions.

Je vais être un peu hors-sujet, mais je vais te donner un exemple du contraire.
J'ai eu un programme où la libération de la mémoire se faisait plus tard dans la version Debug que dans la version Release.
Je l'ai remarqué justement car ça faisait planter la version Release (j'accédais à une zone déjà libérée ET réécrite, alors qu'en Debug on avait pas réécrit par dessus donc les données lues étaient bonnes ).

Pour un truc "simple", je parsais un fichier, construisait un arbre, et recrachais d'autres fichiers.

[jblecanard]

J'ai du mal à voir comment : les fonctions sont appelées avec les mêmes paramètres, s'il n'y à pas d'erreur en debug, il ne peut pas y en avoir en release (sauf éventuel problème d'optimisation trop agressive mais c'est hors sujet je pense).

Simplement parce que l'utilisation réelle crée des conditions et des jeux de données qu'il est pas possible de prévoir avant. Dans ce que je fais, les utilisateurs créent des situations que nous n'avions pas prévues presque à chaque mise en prod (et c'est pas faute d'avoir des batteries de tests bien écrites).

Si vous avez un exemple d'erreur qui peut apparaître en release, je prend.

J'y vais de mon exemple vicieux, rencontré avec GCC 4.7 : si tu implémentes une spécialisation template dans une unité de compilation (un *.cpp par exemple) et que tu oublies de la déclarer dans le header (et que tu linkes en statique, je pense que ça joue mais j'ai pas essayé en dynamique), alors tu peux te retrouver dans une situation ou ta spécialisation est bien appelée en debug et zappée en release. Pour peu que cette spécialisation soit un un peu subtile ou testable à l'échelle uniquement (une fonction de hash par exemple), et il se peut que tes tests passent à côté. Heureusement pour moi, les miens ont bien détecté le problème. Il faut toujours jouer le maximum de tests possibles en release.

[Emmanuel Deloget]

J'y vais de mon exemple vicieux, rencontré avec GCC 4.7 : si tu implémentes une spécialisation template dans une unité de compilation (un *.cpp par exemple) et que tu oublies de la déclarer dans le header (et que tu linkes en statique, je pense que ça joue mais j'ai pas essayé en dynamique), alors tu peux te retrouver dans une situation ou ta spécialisation est bien appelée en debug et zappée en release. Pour peu que cette spécialisation soit un un peu subtile ou testable à l'échelle uniquement (une fonction de hash par exemple), et il se peut que tes tests passent à côté. Heureusement pour moi, les miens ont bien détecté le problème. Il faut toujours jouer le maximum de tests possibles en release.

Lorsque je le peux, j'exécute mes tests unitaires en release sur la machine cible. Ce n'est hélas pas toujours possible, mais ça permet de se mettre en condition d'utilisation (ce qui n'est pas rien : rien ne me dit que mon code écrit pour du 32 bits big endian n'ait pas un comportement différent en 64 bits little endian).

Quelques règles que j'applique :

* Et de manière générale, le code compilé en release est exactement le même que celui compilé en debug - aux assertions près.

* Les macros n'ont donc pas le droit de faire des chose différentes en debug et release.

* l'utilisation de ifdef/ifndef DEBUG/RELEASE est interdit dans mon code et dans le code dont je suis responsable.

Ce qui permet d'avoir quand même une bonne idée de la façon dont le code devrait se comporter dans tous les cas (ce qui facilite le debug lorsqu'un problème est détecté).

[Jean-Marc.Bourguet]

si tu implémentes une spécialisation template dans une unité de compilation (un *.cpp par exemple) et que tu oublies de la déclarer dans le header

Note que c'est un comportement indefini (des que tu penses aux inlines, tu as compris pourquoi).