c'est aussi ce que je pensais en le listant
En outre, avec des asserts bien codées on pourrait avoir la version beaucoup plus parlante et plus light :
jresult some_function( int a, int * b )
{
int ret;
assert_positiv(a);
assert_not_null(b);
ret = some_sub_func( a, *b );
assert(ret, JOK);
....
return JOK;
}
Les asserts sont justement faite pour ces cas. Les asserts sont typiquement là pour tester les cas qui ne devraient pas exister à l'exécution.
Dans cet optique, une assert doit nécessairement provoquer un crash de l'appli, être bloquante car signale un bug, une erreur qu'il faut obligatoirement résoudre.
Rien n'empèche par contre, de loguer dans l'assert, juste avant le "exit".
Pour ma part, je n'utilise pas beaucoup les exceptions (ça dépend aussi des framework) mais je pense qu'un bon traitement des erreurs est multiple :
- des assert pour les entrées / sorties de fonctions. Tout ce qui doit être valide mais sans aucune action avec l'utilisateur (typiquement un pointeur ne devant pas être null). Et ça doit crasher, les asserts doivent crasher pendant le dev et ne seront de toute manière pas compilées (ou seulement le log sera compilé)
- des tests "classiques" avec affichage pour tout problème que l'utilisateur peut contrôler
- des exceptions, des try/catch au milieu permettant de faire remonter les problèmes (très pratique lorsque l'erreur survient dans une routine mais que le traitement de celle-ci ne se fera que dans des couches plus haute)
[^] # Re: Vive les exceptions !
Posté par CrEv (site web personnel) . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 1.
En outre, avec des asserts bien codées on pourrait avoir la version beaucoup plus parlante et plus light :
Les asserts sont justement faite pour ces cas. Les asserts sont typiquement là pour tester les cas qui ne devraient pas exister à l'exécution.
Dans cet optique, une assert doit nécessairement provoquer un crash de l'appli, être bloquante car signale un bug, une erreur qu'il faut obligatoirement résoudre.
Rien n'empèche par contre, de loguer dans l'assert, juste avant le "exit".
Pour ma part, je n'utilise pas beaucoup les exceptions (ça dépend aussi des framework) mais je pense qu'un bon traitement des erreurs est multiple :
- des assert pour les entrées / sorties de fonctions. Tout ce qui doit être valide mais sans aucune action avec l'utilisateur (typiquement un pointeur ne devant pas être null). Et ça doit crasher, les asserts doivent crasher pendant le dev et ne seront de toute manière pas compilées (ou seulement le log sera compilé)
- des tests "classiques" avec affichage pour tout problème que l'utilisateur peut contrôler
- des exceptions, des try/catch au milieu permettant de faire remonter les problèmes (très pratique lorsque l'erreur survient dans une routine mais que le traitement de celle-ci ne se fera que dans des couches plus haute)