Ah, les erreurs, c'est pas forcément les tiennes :)
Exemple 1: les erreurs de serveurs extérieurs.
Tu fais un appel XML-RPC à un serveur qui te renvoie une page HTML pour te dire "en cours de maintenance". (ça m'est arrivé plusieurs fois avec Wordpress.com). Boum, le parser XML !
Exemple 2: les erreurs de tes collègues
Ton collègue Pierre vient te voir: "Y'a un bug dans ton module dans ton module foo". Après une heure de recherche, tu te rends compte que Pierre a appelé ton module avec un nombre négatif, alors que ça n'a de sens qu'avec des nombres positifs. Si tu avais utilisé un assert(), le programme aurait crashé simplement avec un message clair que tu as écrit à l'attention des collègues qui utilisent mal ton code.
Alors à part ça, pour le premier exemple : à Flock on a défini une classe flockIError adapté aux erreurs qui viennent du serveur. Ça nous permet de mettre un code d'erreur serveur, un message d'erreur serveur, un code d'erreur Flock (unifié entre les services), et un message d'erreur Flock. Le message d'erreur Flock est localisé, comme ça on peut le montrer à l'utilisateur ("mauvais mot de passe", "serveur indisponible", "permissions insuffisante"...). http://lxr.flock.com/source/flock/mozilla/flock/base/common/(...)
Parallèlement à ça, on a un logger qui a différents niveaux : erreur, warning, info, debug.
Pour le deuxième exemple, l'astuce c'est de mettre tout tes assert() dans du code de préprocesseur. Comme ça quand tu développes le moindre bug provoque un crash (c'est mieux pour débugguer) mais pour les releases tu changes les options de compilation pour désactiver les assert() et les erreurs ne provoquent plus de crash.
Un peu dans cette idée, pour Flock les exceptions Javascript (Flock est principalement développé en Javascript) qui ne sont pas capturées provoquent une boite de dialogue alert(). C'est très agaçant, et ça donne envie de réparer l'exception très vite :).
[^] # Re: Ma réponse :
Posté par Erwan . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 3.
Exemple 1: les erreurs de serveurs extérieurs.
Tu fais un appel XML-RPC à un serveur qui te renvoie une page HTML pour te dire "en cours de maintenance". (ça m'est arrivé plusieurs fois avec Wordpress.com). Boum, le parser XML !
Exemple 2: les erreurs de tes collègues
Ton collègue Pierre vient te voir: "Y'a un bug dans ton module dans ton module foo". Après une heure de recherche, tu te rends compte que Pierre a appelé ton module avec un nombre négatif, alors que ça n'a de sens qu'avec des nombres positifs. Si tu avais utilisé un assert(), le programme aurait crashé simplement avec un message clair que tu as écrit à l'attention des collègues qui utilisent mal ton code.
Alors à part ça, pour le premier exemple : à Flock on a défini une classe flockIError adapté aux erreurs qui viennent du serveur. Ça nous permet de mettre un code d'erreur serveur, un message d'erreur serveur, un code d'erreur Flock (unifié entre les services), et un message d'erreur Flock. Le message d'erreur Flock est localisé, comme ça on peut le montrer à l'utilisateur ("mauvais mot de passe", "serveur indisponible", "permissions insuffisante"...).
http://lxr.flock.com/source/flock/mozilla/flock/base/common/(...)
Parallèlement à ça, on a un logger qui a différents niveaux : erreur, warning, info, debug.
Pour le deuxième exemple, l'astuce c'est de mettre tout tes assert() dans du code de préprocesseur. Comme ça quand tu développes le moindre bug provoque un crash (c'est mieux pour débugguer) mais pour les releases tu changes les options de compilation pour désactiver les assert() et les erreurs ne provoquent plus de crash.
Un peu dans cette idée, pour Flock les exceptions Javascript (Flock est principalement développé en Javascript) qui ne sont pas capturées provoquent une boite de dialogue alert(). C'est très agaçant, et ça donne envie de réparer l'exception très vite :).