Je programme énormément avec les assert, mais en le faisant de manière intélligente. Les assertion ne sont pas limitées à ce que fournit <assert.h> c'est à dire pas grand chose.
Dans mon code, il y a toujours différents types d'assertions. Elle prennent toutes au moins une condition à tester et un méssage d'erreur ce qui donne :
assert_fail(a < b, "error in library toto, invalid parameter for bipbip");
Ca c'est le cas de base, en général il y a plusieurs niveau d'assertion, ce qui me permet de définir qu'elle assertions je veux désactiver à la compilation.
Ensuite, j'utilise beaucoup des assertion avec valeur de retour du type :
check(ptr != NULL, "cannot allocate memory in library toto", ERR_MEMORY);
qui va faire le test et en cas d'erreur logger le message et faire un return ERR_MEMORY. (Ce n'est plus vraiment une assertion ici car il y a un effet de bord, mais je le met quand même dans la même catégorie car l'utilisation est globalement la même. La seule différence c'est que en général je passe deux tests différents, le premier est complet mais lent et fait en mode debug, le deuxième est plus rapide et fait en mode perf, dans tous les cas les check ne sont jamais désactivés.)
Au final, ce que je fais reviens au même que toi sauf que je cache toute la merde dans un fichier include qui contient un max de macros pour gérer plein de cas et logger les messages et/ou les afficher dans la console. Se système à l'avantage de garder un code plus agréable à lire à mon gout, et surtout me permet de facilement désactiver les assert suivant le type de compilation.
Au sujet du désactivage pour la version finale, je comprend que cela puisse en choquer certains, mais pour moi c'est indispensable dans mon code. J'écrit notament des programmes qui font des calculs mathématiques très lourds et complexes. Pour garder le truc relativement simple à comprendre et à maintenir, je découpe en de nombreuses sous fonction qui sont simple à documenter, que l'on comprend facilement donc débuggage beaucoup plus facile.
Pour toutes ces fonction je test tous les paramètres en entrées et je fais des vérifications en sorties pour vérifier au maximum que tout ces bien passé.
Ces vérifications sont extrèmement couteuses et si je laisse tourner mon programme au lieu de tourner pendant deux semaines, c'est dix ans qu'il va falloir que j'attende.
J'utilise des vérifications très complètes pendant le dévellopement, mais pendant les phases de calcul, je les réduit au minimum, et chez moi ça ce fait juste en faisant un "make perf" au lieu d'un "make" ou "make debug".
[^] # Re: Vive les exceptions !
Posté par beagf . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 2.
Dans mon code, il y a toujours différents types d'assertions. Elle prennent toutes au moins une condition à tester et un méssage d'erreur ce qui donne :
assert_fail(a < b, "error in library toto, invalid parameter for bipbip");
Ca c'est le cas de base, en général il y a plusieurs niveau d'assertion, ce qui me permet de définir qu'elle assertions je veux désactiver à la compilation.
Ensuite, j'utilise beaucoup des assertion avec valeur de retour du type :
check(ptr != NULL, "cannot allocate memory in library toto", ERR_MEMORY);
qui va faire le test et en cas d'erreur logger le message et faire un return ERR_MEMORY. (Ce n'est plus vraiment une assertion ici car il y a un effet de bord, mais je le met quand même dans la même catégorie car l'utilisation est globalement la même. La seule différence c'est que en général je passe deux tests différents, le premier est complet mais lent et fait en mode debug, le deuxième est plus rapide et fait en mode perf, dans tous les cas les check ne sont jamais désactivés.)
Au final, ce que je fais reviens au même que toi sauf que je cache toute la merde dans un fichier include qui contient un max de macros pour gérer plein de cas et logger les messages et/ou les afficher dans la console. Se système à l'avantage de garder un code plus agréable à lire à mon gout, et surtout me permet de facilement désactiver les assert suivant le type de compilation.
Au sujet du désactivage pour la version finale, je comprend que cela puisse en choquer certains, mais pour moi c'est indispensable dans mon code. J'écrit notament des programmes qui font des calculs mathématiques très lourds et complexes. Pour garder le truc relativement simple à comprendre et à maintenir, je découpe en de nombreuses sous fonction qui sont simple à documenter, que l'on comprend facilement donc débuggage beaucoup plus facile.
Pour toutes ces fonction je test tous les paramètres en entrées et je fais des vérifications en sorties pour vérifier au maximum que tout ces bien passé.
Ces vérifications sont extrèmement couteuses et si je laisse tourner mon programme au lieu de tourner pendant deux semaines, c'est dix ans qu'il va falloir que j'attende.
J'utilise des vérifications très complètes pendant le dévellopement, mais pendant les phases de calcul, je les réduit au minimum, et chez moi ça ce fait juste en faisant un "make perf" au lieu d'un "make" ou "make debug".