Cachez cette erreur que je ne saurais voir !

Qu'y a-t-il de plus agaçant qu'une application qui plante lamentablement sans le moindre message ? Qu'y a-t-il de plus compliqué pour le développeur à déboguer que ce type d'application ?

Ça fait assez longtemps que j'observe cette tendance qu'il y a chez de nombreux développeurs (y compris moi-même à une certaine époque) à cacher les erreurs, les exceptions, à tout faire pour que l'application ne quitte pas inopinément, au risque de mettre en péril la fiabilité des résultats obtenus. On essaie de faire croire à l'utilisateur/client qu'il n'y a jamais de problème. Mais tout développeur sait que cela est illusoire. Une sorte Graal qu'il est impossible d'atteindre. On a beau utiliser des tests unitaires, essayer de prévoir tous les cas d'erreurs, il y a toujours une situation qu'on n'a pas anticipée et qui plante notre application qu'on croyait pourtant si robuste.

J'ai pu également observer qu'on a l'air beaucoup plus crédible et professionnel lorsqu'on a une trace ou un code d'erreur lorsqu'il y a plantage. L'idéal est de pouvoir produire une image de la pile dans un fichier au moment de l'erreur, et de la demander au client : vous gagnez en crédibilité car vous avez envisagé l'improbable. De plus, vous récupérez des informations précieuses qui vous permettent de comprendre et de corriger rapidement le bug. Un code d'erreur est souvent suffisant.

Les assertions (assert), par exemple, peuvent être un outil précieux. Lorsque je débutais, on m'a appris, comme une sorte de dogme, que les assertions ne devaient être utilisées que dans du code compilé en version debug, mais ne devaient pas apparaître dans la version compilée en release. Je me rends compte maintenant, pour avoir violé cette règle, combien cela est une erreur. Une assertion sur un pointeur NULL à un endroit où on ne s'y attend pas et qu'on ne sait pas rattraper, par exemple, évite une erreur anonyme. Un assert indique la ligne de code et la condition qui a provoqué l'arrêt. Une information des plus précieuse pour corriger rapidement une erreur grave.

À mon sens, le plus important est la maîtrise de l'erreur. Avoir le contrôle et le montrer, pour gagner la confiance du client ou de l'utilisateur. Bien entendu, aucune erreur, c'est mieux !