Ça, ça ne va pas changer, je déteste les exceptions en C++. Et je ne vois pas bien où je pourrais en mettre.
J'ai un jour dû écrire un logiciel en C de haute disponibilité, qui devait tourner 24h/24, 7j/7, sur un PC industriel équipé d'un watchdog, histoire qu'il reboot automatiquement si mon logiciel devait planter. Du coup, la plupart de mes fonctions comportaient pléthore de if dont l'unique objet était de remonter à la fonction appelante les erreurs détectées dans les fonctions appelées. Je trouvais que cela rendait le programme presque illisible, car il était difficile de distinguer parmi tous ces if lesquels étaient 'algorithmiques', et lesquels étaient dédiés à la gestion d'erreurs.
Pour améliorer cela, j'ai implémenté en C, en m'appuyant sur la bibliothèque setjmp, un mécanisme, sous forme d'un jeu de macros, dont je me suis rendu compte plus tard qu'il s'apparentait aux exceptions C++, que je ne connaissais pas à l'époque. D'ailleurs, quand je suis passé au C++, j'ai réimplémenté ces mêmes macros en m'appuyant sur les exceptions, au lieu de la bibliothèque setjmp. J'utilise toujours ces macros pour la gestion des erreurs, et, bien que, par défaut, elles s'appuient sur les exceptions C++, on peut, à l'aide d'une option de compilation, basculer sur la bibliothèque setjmp, pour une utilisation dans un environnement où les exceptions ne seraient pas disponibles.
Quand ma production consistait essentiellement en utilitaires en ligne de commande, l'exception était interceptée grosso-modo dans le main pour afficher un message d'erreur. Par contre, depuis que j'écris des daemon, l'exception est interceptée à la fonction racine du thread dans lequel elle est lancée, pour afficher un message d'erreur dans un log, voire relayer ce message au client, avant de terminer le thread en question. Mais le thread principal continue toujours de tourner, ainsi que les autres threads, prêts à répondre aux requêtes des différents clients.
Pour les interfaces graphiques, l'exception est interceptée dans la boucle de gestion des événements. Par exemple, si l'utilisateur valide un formulaire en oubliant de remplir un champ obligatoire, une exception est lancée qui remonte jusqu'à cette boucle, affiche un message signalant la nécessité de remplir le champs oublié, et ensuite laisse tout loisir à l'utilisateur de remplir le champ en question, comme s'il ne s'était rien passé.
En ce qui me concerne, les exceptions (ou la setjmp en C) facilitent grandement le développement de logiciels...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # De l’utilité des exceptions.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 8. Dernière modification le 20 juillet 2016 à 15:01.
J'ai un jour dû écrire un logiciel en C de haute disponibilité, qui devait tourner 24h/24, 7j/7, sur un PC industriel équipé d'un watchdog, histoire qu'il reboot automatiquement si mon logiciel devait planter. Du coup, la plupart de mes fonctions comportaient pléthore de if dont l'unique objet était de remonter à la fonction appelante les erreurs détectées dans les fonctions appelées. Je trouvais que cela rendait le programme presque illisible, car il était difficile de distinguer parmi tous ces if lesquels étaient 'algorithmiques', et lesquels étaient dédiés à la gestion d'erreurs.
Pour améliorer cela, j'ai implémenté en C, en m'appuyant sur la bibliothèque setjmp, un mécanisme, sous forme d'un jeu de macros, dont je me suis rendu compte plus tard qu'il s'apparentait aux exceptions C++, que je ne connaissais pas à l'époque. D'ailleurs, quand je suis passé au C++, j'ai réimplémenté ces mêmes macros en m'appuyant sur les exceptions, au lieu de la bibliothèque setjmp. J'utilise toujours ces macros pour la gestion des erreurs, et, bien que, par défaut, elles s'appuient sur les exceptions C++, on peut, à l'aide d'une option de compilation, basculer sur la bibliothèque setjmp, pour une utilisation dans un environnement où les exceptions ne seraient pas disponibles.
Quand ma production consistait essentiellement en utilitaires en ligne de commande, l'exception était interceptée grosso-modo dans le
mainpour afficher un message d'erreur. Par contre, depuis que j'écris des daemon, l'exception est interceptée à la fonction racine du thread dans lequel elle est lancée, pour afficher un message d'erreur dans un log, voire relayer ce message au client, avant de terminer le thread en question. Mais le thread principal continue toujours de tourner, ainsi que les autres threads, prêts à répondre aux requêtes des différents clients.Pour les interfaces graphiques, l'exception est interceptée dans la boucle de gestion des événements. Par exemple, si l'utilisateur valide un formulaire en oubliant de remplir un champ obligatoire, une exception est lancée qui remonte jusqu'à cette boucle, affiche un message signalant la nécessité de remplir le champs oublié, et ensuite laisse tout loisir à l'utilisateur de remplir le champ en question, comme s'il ne s'était rien passé.
En ce qui me concerne, les exceptions (ou la setjmp en C) facilitent grandement le développement de logiciels...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...