Mon code ne contiens aucun bug, uniquement des fonctionnalités non documentées :D
Plus sérieusement, j'utilise de moins en moins printf, je préfère balancer des exceptions, qui elles font se terminer le programme avec un message qui indique quelle condition n'a pas été respectée.
Il se peut même que je rattrape l'exception si le problème n'est pas trop grave pour afficher un simple avertissement, ou mettre le problème dans le journal.
Quelqu'un a dis plus haut que le message est parfois délicat à trouver… je ne suis pas d'accord. L'exception peut parfois être lisible pour un utilisateur, mais je ne suis pas sûr que ce soit le but: je préfère quelque chose qui m'indique quelle condition à merdé. Si c'est du runtime_error, alors on peut savoir et dire ce qu'il s'est passé: fichier de configuration corrompu ou manquant, problème de connexion réseau, plus de papier dans l'imprimante… et la, l'utilisateur peut régler le problème lui-même.
Mais si c'est dû à un bug, il n'a pas à comprendre, de toute façon il ne pourra rien y faire. Il faut uniquement lui donner une procédure pour envoyer un rapport d'erreur correcte, et pourquoi pas l'envoyer de façon automatisée.
Le débogueur est toujours utile, mais il y a des cas ou il ne fonctionne pas (j'ai déjà vu des breakpoint faire planter l'application), et ceux disponibles sous linux ont des interfaces tout de même assez pénibles selon moi.
Sinon, j'aime aussi beaucoup l'idée de l'analyse statique, mais je n'ai pas eu l'occasion d'essayer de tels outils malheureusement.
# Bien sûr que non!
Posté par freem . En réponse au journal Un debugger est-il indispensable ?. Évalué à 2.
Mon code ne contiens aucun bug, uniquement des fonctionnalités non documentées :D
Plus sérieusement, j'utilise de moins en moins printf, je préfère balancer des exceptions, qui elles font se terminer le programme avec un message qui indique quelle condition n'a pas été respectée.
Il se peut même que je rattrape l'exception si le problème n'est pas trop grave pour afficher un simple avertissement, ou mettre le problème dans le journal.
Quelqu'un a dis plus haut que le message est parfois délicat à trouver… je ne suis pas d'accord. L'exception peut parfois être lisible pour un utilisateur, mais je ne suis pas sûr que ce soit le but: je préfère quelque chose qui m'indique quelle condition à merdé. Si c'est du runtime_error, alors on peut savoir et dire ce qu'il s'est passé: fichier de configuration corrompu ou manquant, problème de connexion réseau, plus de papier dans l'imprimante… et la, l'utilisateur peut régler le problème lui-même.
Mais si c'est dû à un bug, il n'a pas à comprendre, de toute façon il ne pourra rien y faire. Il faut uniquement lui donner une procédure pour envoyer un rapport d'erreur correcte, et pourquoi pas l'envoyer de façon automatisée.
Le débogueur est toujours utile, mais il y a des cas ou il ne fonctionne pas (j'ai déjà vu des breakpoint faire planter l'application), et ceux disponibles sous linux ont des interfaces tout de même assez pénibles selon moi.
Sinon, j'aime aussi beaucoup l'idée de l'analyse statique, mais je n'ai pas eu l'occasion d'essayer de tels outils malheureusement.