La gestion des erreurs est quelque chose de très difficile. Les exceptions permettent heureusement d'avoir du code plus propre, mais il reste la difficulté de bien les gérer.
Toutefois, dans ce domaine la solution parfaite n'existe pas. Afin de rendre le programme robuste, il faut gérer les exceptions, mais intelligemment.
Moi, je pars du principe de gérer tout d'abord les exceptions de manière grossières, c'est à dire, que tous les comportement exceptionnels mènent à l'arrêt du programme (après log).
Ensuite, j'essaie progressivement d'améliorer la tolérance du programme afin de gérer de plus en plus de cas. Sachant que si quelque chose n'est pas précisément géré, le programme s'arrêtera a nouveau.
Et c'est là qu'il est important de savoir ce que l'on peut récupérer ou pas. Le traitement d'exception lui même étant susceptible de lever des exceptions, le code peut devenir trop compliqué.
De manière générale, je définis une liste d'exception que je ne vais jamais gérer et que je considérerai directement comme menant à l'arrêt du programme. Exemple: problèmes d'io sur le disque ou dans la base de donnée.
Enfin, la gestion des erreurs ne doit pas être considérée que par rapport à elle-même. Afin d'avoir une gestion simplifiée, il est indispensable de factoriser le programme de manière adéquate et d'arriver à regrouper la gestion des erreurs et ne pas (trop) la mélanger au code fonctionnel.
A mon avis, l'arrêt est souvent une solution très sage quand on a pas la certitude de pouvoir traîter le problème de manière ciblée. Dans certains cas, on peut envisager un programme externe qui va relancer le programme dès qu'il constate son arrêt (avec un timer également).
# le mieux est l'ennemi du bien
Posté par RB . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 1.
Toutefois, dans ce domaine la solution parfaite n'existe pas. Afin de rendre le programme robuste, il faut gérer les exceptions, mais intelligemment.
Moi, je pars du principe de gérer tout d'abord les exceptions de manière grossières, c'est à dire, que tous les comportement exceptionnels mènent à l'arrêt du programme (après log).
Ensuite, j'essaie progressivement d'améliorer la tolérance du programme afin de gérer de plus en plus de cas. Sachant que si quelque chose n'est pas précisément géré, le programme s'arrêtera a nouveau.
Et c'est là qu'il est important de savoir ce que l'on peut récupérer ou pas. Le traitement d'exception lui même étant susceptible de lever des exceptions, le code peut devenir trop compliqué.
De manière générale, je définis une liste d'exception que je ne vais jamais gérer et que je considérerai directement comme menant à l'arrêt du programme. Exemple: problèmes d'io sur le disque ou dans la base de donnée.
Enfin, la gestion des erreurs ne doit pas être considérée que par rapport à elle-même. Afin d'avoir une gestion simplifiée, il est indispensable de factoriser le programme de manière adéquate et d'arriver à regrouper la gestion des erreurs et ne pas (trop) la mélanger au code fonctionnel.
A mon avis, l'arrêt est souvent une solution très sage quand on a pas la certitude de pouvoir traîter le problème de manière ciblée. Dans certains cas, on peut envisager un programme externe qui va relancer le programme dès qu'il constate son arrêt (avec un timer également).