Dans les slides, quand on remplace erreur par bug ca devient franchement cocasse par endroits : "Un programme qui ne gère pas les bugs est imprévisible en cas de bug".
Plus sérieusement, j'ai franchement l'impression que quand on parle de gestion d'erreur ici on parle plutôt du "meilleur système pour que tout parte pas en vrille quand on a un bug".
Or par définition la plupart des softs deviennent complètement imprévisibles en cas de bug, un gestionnaire d'erreur peut aider, mais peu aussi rendre l'application plus opaque (récupération d'erreur qui rétabli l'application, mais dans un état incorrect - il est très difficile de programmer une récupération d'erreur ... sans ajouter de bugs).
Par exemple : une souscription à un service sur son téléphone portable doit pouvoir marcher même si la base de données est momentanément hors d'usage. Ce n'est pas une erreur. Ce n'est pas un bug. C'est une fonctionnalité. Si le truc doit être programmé pour permettre le coup de téléphone même si une partie du système est en vrac, c'est une fonctionnalité, ca peut se faire sans gestion d'erreur. A contrario,
si le truc génère une erreur lorsque la base de données est offline, c'est un bug.
Pas facile a exprimer mais en gros l'idée est que, un gestionnaire d'erreur, aussi bien qu'il soit, n'est pas la pour récupérer les bugs. Des bugs il y en a toujours, des erreurs aussi. La différence c'est que l'on programme la réaction aux erreurs pour les récupérer, des erreurs qui ne sont pas des bugs, des erreurs dont le développeur est conscient.
Donc je trouve ce brainstorming sur la gestion d'erreur très intéressant point de vue architecture, mais il me donne l'impression qu'on espère récupérer les bugs en même temps que les erreurs, alors qu'a mon sens c'est totalement impossible.
# Gestion d'erreur ou de bugs ?
Posté par Anonyme . En réponse au journal Retour sur le Isaac Meeting 2008. Évalué à 7.
Plus sérieusement, j'ai franchement l'impression que quand on parle de gestion d'erreur ici on parle plutôt du "meilleur système pour que tout parte pas en vrille quand on a un bug".
Or par définition la plupart des softs deviennent complètement imprévisibles en cas de bug, un gestionnaire d'erreur peut aider, mais peu aussi rendre l'application plus opaque (récupération d'erreur qui rétabli l'application, mais dans un état incorrect - il est très difficile de programmer une récupération d'erreur ... sans ajouter de bugs).
Par exemple : une souscription à un service sur son téléphone portable doit pouvoir marcher même si la base de données est momentanément hors d'usage. Ce n'est pas une erreur. Ce n'est pas un bug. C'est une fonctionnalité. Si le truc doit être programmé pour permettre le coup de téléphone même si une partie du système est en vrac, c'est une fonctionnalité, ca peut se faire sans gestion d'erreur. A contrario,
si le truc génère une erreur lorsque la base de données est offline, c'est un bug.
Pas facile a exprimer mais en gros l'idée est que, un gestionnaire d'erreur, aussi bien qu'il soit, n'est pas la pour récupérer les bugs. Des bugs il y en a toujours, des erreurs aussi. La différence c'est que l'on programme la réaction aux erreurs pour les récupérer, des erreurs qui ne sont pas des bugs, des erreurs dont le développeur est conscient.
Donc je trouve ce brainstorming sur la gestion d'erreur très intéressant point de vue architecture, mais il me donne l'impression qu'on espère récupérer les bugs en même temps que les erreurs, alors qu'a mon sens c'est totalement impossible.