mais c'est normal que ça arrête l'application comme une grosse brutasse !
l'assert (et je répond ici au commentaire du dessus) ne doit pas être compilée en release.
Une assert ne correspond pas à tous les cas d'erreur mais doit permettre, lors du développement, de tester les pre et post conditions des fonctions.
Si une assert apparaît, alors on est clairement dans un cas où on aurait jamais du être et pour lequel on a pas de sortie propre possible (ex d'une fonction devant retourner tout le temps un pointeur ... sauf que le pointeur, pour une raison indépendante de cette fonction, est nul)
Pour les autres cas il y a les autres gestion d'erreurs.
Il faut, à mon avis, vraiment séparer les types d'erreurs et leurs traitement.
Maintenant, concernant les logs, rien n'empèche (et c'est ce que je fais en général) d'avoir des fonctions prenant des messages en parametre :
a = my_func();
assert_not_null(a, "my_func return a bad pointer plop plop plop");
Enfin, oui, l'assert ne doit plus exister en release, et ce pour plusieurs raisons :
d'une part le code d'assert termine normalement par un exit donc ça crash forcément. D'autre part l'assert étant placée pour tester un cas n'apparaissant normalement pas, l'application crachera de toute manière juste après ou un peu plus loin, ou beaucoup plus loin mais on ne saura jamais pourquoi...
Et oui, niveau perf le gain peut être important. En utilisant les asserts comme pre/post conditions des fonctions (de la majorité) il devient évident que supprimer de quelques à une dizaine de tests par fonction peut avoir des impacts sur la performance globale du programme.
Mais ce que j'ai l'impression en lisant les commentaires des "anti" assert est qu'ils croient qu'il n'y a qu'une façon de traiter les erreurs alors que la méthode "parfaite" n'est qu'un mix de toutes les autres.
ps : non, les fan d'assert n'auraient pas forcément écrit un code plus petit, mais peut être plus grand justement, du fait d'en coller partout où on ne metterait pas un test car on penserait ça inutile alors que...
[^] # 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.
l'assert (et je répond ici au commentaire du dessus) ne doit pas être compilée en release.
Une assert ne correspond pas à tous les cas d'erreur mais doit permettre, lors du développement, de tester les pre et post conditions des fonctions.
Si une assert apparaît, alors on est clairement dans un cas où on aurait jamais du être et pour lequel on a pas de sortie propre possible (ex d'une fonction devant retourner tout le temps un pointeur ... sauf que le pointeur, pour une raison indépendante de cette fonction, est nul)
Pour les autres cas il y a les autres gestion d'erreurs.
Il faut, à mon avis, vraiment séparer les types d'erreurs et leurs traitement.
Maintenant, concernant les logs, rien n'empèche (et c'est ce que je fais en général) d'avoir des fonctions prenant des messages en parametre :
a = my_func();
assert_not_null(a, "my_func return a bad pointer plop plop plop");
Enfin, oui, l'assert ne doit plus exister en release, et ce pour plusieurs raisons :
d'une part le code d'assert termine normalement par un exit donc ça crash forcément. D'autre part l'assert étant placée pour tester un cas n'apparaissant normalement pas, l'application crachera de toute manière juste après ou un peu plus loin, ou beaucoup plus loin mais on ne saura jamais pourquoi...
Et oui, niveau perf le gain peut être important. En utilisant les asserts comme pre/post conditions des fonctions (de la majorité) il devient évident que supprimer de quelques à une dizaine de tests par fonction peut avoir des impacts sur la performance globale du programme.
Mais ce que j'ai l'impression en lisant les commentaires des "anti" assert est qu'ils croient qu'il n'y a qu'une façon de traiter les erreurs alors que la méthode "parfaite" n'est qu'un mix de toutes les autres.
ps : non, les fan d'assert n'auraient pas forcément écrit un code plus petit, mais peut être plus grand justement, du fait d'en coller partout où on ne metterait pas un test car on penserait ça inutile alors que...