Je ne fais pas du tout de C++ et du coup ce passage m'intrigue profondément. Je ne veux pas lancer de troll hein, mais ça m'aurait vraiment intéressé de connaître ces raisons.
Alors, en premier lieu, je dois corriger un point faux (imprécis) de mon article. La librairie standard c++ utilise les exceptions, mais dans certains cas limités, comme une allocation ratée. Mais l'ouverture d'un fichier, la recherche d'un élément qui n'existe pas, ..., sont gérées avec des fonctions de test is_open, ou des valeurs sentinelles conteneur.end().
Concernant l'usage, certains se plaignent des performances ou de l'augmentation de la taille du code, mais c'est très controversé et discutable en fonction du contexte de travail.
Un autre problème, soulevé dans mon journal, est que les exceptions ne sont pas du tout listées dans le prototypes des fonctions, et donc qu'il est difficile de savoir, sans lire la documentation, qu'une fonction peut lancer une exception, et les choses peuvent évoluer sans prévenir.
Un autre point important est la difficulté d'écrire du code qui résiste bien aux exceptions, l'idée étant que si une exception est lancée, tu dois pouvoir te retrouver dans un état stable et prévisible après récupération de l'exception, sinon il ne sert à rien de survire à l'erreur si c'est pour se retrouver dans un état indéterminé.
[^] # Re: C++ et exceptions
Posté par Guillaum (site web personnel) . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 5.
Alors, en premier lieu, je dois corriger un point faux (imprécis) de mon article. La librairie standard c++ utilise les exceptions, mais dans certains cas limités, comme une allocation ratée. Mais l'ouverture d'un fichier, la recherche d'un élément qui n'existe pas, ..., sont gérées avec des fonctions de test
is_open, ou des valeurs sentinellesconteneur.end().Concernant l'usage, certains se plaignent des performances ou de l'augmentation de la taille du code, mais c'est très controversé et discutable en fonction du contexte de travail.
Un autre problème, soulevé dans mon journal, est que les exceptions ne sont pas du tout listées dans le prototypes des fonctions, et donc qu'il est difficile de savoir, sans lire la documentation, qu'une fonction peut lancer une exception, et les choses peuvent évoluer sans prévenir.
Un autre point important est la difficulté d'écrire du code qui résiste bien aux exceptions, l'idée étant que si une exception est lancée, tu dois pouvoir te retrouver dans un état stable et prévisible après récupération de l'exception, sinon il ne sert à rien de survire à l'erreur si c'est pour se retrouver dans un état indéterminé.