Journal : Qu'est-ce que bien gérer les erreurs dans ses programmes ?
Posté par Nicolas Boulay () le 14 décembre 2007
La question métaphysique du jour : comment bien gérer les erreurs ?
Il y a déjà plusieurs types d'erreurs: celles qui relèvent de la mauvaise utilisation de code, elle pourrait se traiter avec des assert(), il y a celle qui remonte un mauvais fonctionnement à l'étage du dessus, et celle entre les deux, qui peuvent servir parfois à effectuer des "scans" de fonctionnalités (genre on charge tous les noyau réseau un par un pour trouver le bon driver de sa carte).
Les problèmes surviennent lorsque du code qui devrait retourner un assert() et donc crasher en cas d'erreur font un simple "return error"; et qui a le malheur de faire une exécution partielle du code. En général, 2 ou 3 appels de fonctions différentes de la lib en question plus tard, tout va se viander aléatoirement.
Donc, il faut déjà prévoir quoi faire en cas d'erreurs au plus bas niveau et ne remonter qu'en cas d'impossibilité de gérer le problème à ce niveau et encore, en le faisant proprement (par exemple, un retour de malloc à 0 ?).
Proprement, cela veut dire peut-être de séparer fonction de test de validité des paramètres, et exécution proprement dite de la fonction, cela permet d'éviter les exécutions partielles (imaginez une fonction de lib qui retourne une erreur en s'étant exécuter à moitie dans un cas qui n'entraine pas une erreur fatal de l'ensemble).
Souvent dans les exemples d'utilisation, la gestion des erreurs est mise de coté pour éviter d'alourdir un exemple. Cela démontre déjà que la gestion d'erreur à tendance à brouiller l'algorithme de base. Je trouve que cela renforce le principe de base de bien séparer exécution et traitement d'erreur.
Il y a maintenant les gestions d'exception pour faire cela. Je n'ai jamais vraiment coder avec, mais je n'ai jamais non plus vu un véritable enthousiasme pour ce système.
J'aurais tendance à éviter toute gestion d'erreurs qui entraîne un crash. Aucun utilisateur n'aime voir un crash, surtout dans l'embarqué. Cela me rappelle une certaine central inertielle qui partait en autotest sur une exception Ada. J'aurais tendance à interdire formellement tout code qui interrompt la fonctionnalité.
Connaissez vous des règles génériques pour déterminer la conduite à tenir en cas de retour d'erreur ?
Qu'est-ce que vous conseillez donc pour faire propre ?
Il y a déjà plusieurs types d'erreurs: celles qui relèvent de la mauvaise utilisation de code, elle pourrait se traiter avec des assert(), il y a celle qui remonte un mauvais fonctionnement à l'étage du dessus, et celle entre les deux, qui peuvent servir parfois à effectuer des "scans" de fonctionnalités (genre on charge tous les noyau réseau un par un pour trouver le bon driver de sa carte).
Les problèmes surviennent lorsque du code qui devrait retourner un assert() et donc crasher en cas d'erreur font un simple "return error"; et qui a le malheur de faire une exécution partielle du code. En général, 2 ou 3 appels de fonctions différentes de la lib en question plus tard, tout va se viander aléatoirement.
Donc, il faut déjà prévoir quoi faire en cas d'erreurs au plus bas niveau et ne remonter qu'en cas d'impossibilité de gérer le problème à ce niveau et encore, en le faisant proprement (par exemple, un retour de malloc à 0 ?).
Proprement, cela veut dire peut-être de séparer fonction de test de validité des paramètres, et exécution proprement dite de la fonction, cela permet d'éviter les exécutions partielles (imaginez une fonction de lib qui retourne une erreur en s'étant exécuter à moitie dans un cas qui n'entraine pas une erreur fatal de l'ensemble).
Souvent dans les exemples d'utilisation, la gestion des erreurs est mise de coté pour éviter d'alourdir un exemple. Cela démontre déjà que la gestion d'erreur à tendance à brouiller l'algorithme de base. Je trouve que cela renforce le principe de base de bien séparer exécution et traitement d'erreur.
Il y a maintenant les gestions d'exception pour faire cela. Je n'ai jamais vraiment coder avec, mais je n'ai jamais non plus vu un véritable enthousiasme pour ce système.
J'aurais tendance à éviter toute gestion d'erreurs qui entraîne un crash. Aucun utilisateur n'aime voir un crash, surtout dans l'embarqué. Cela me rappelle une certaine central inertielle qui partait en autotest sur une exception Ada. J'aurais tendance à interdire formellement tout code qui interrompt la fonctionnalité.
Connaissez vous des règles génériques pour déterminer la conduite à tenir en cas de retour d'erreur ?
Qu'est-ce que vous conseillez donc pour faire propre ?
> Lire le journal (80 commentaires, moyenne: 2,4).
Vous avez demandé le commentaire #891997.
Run by 
Cette page a été générée par Templeet en 0.0575s (dont 0.0048 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Shell scripting
Je profite du topic pour demander comment vous gérez les erreurs en shell ? Quelles techniques ? Existe-t-il une bibliothèque de fonctions utiles pour ce genre de cas ? Actuellement j'utilise des système un peu batards qui exploitent les variables standard (genre $? et compagnie) et les traps systèmes mais je trouve cela très "sale" car j'ai toujours cette impression de "réinventer" la roue.
Xavier Maillard
Rapport Cedras
NON A NICOLAS SARKOZY
NON A NICOLAS SARKOZY
[^]Re: Shell scripting
Yep, j'écris mes programmes shell avec Python. Fastoche.
[^]Re: Shell scripting
Ce n'est pas le genre de réponse que j'attendais ;) Si cela ne tenait qu'à moi, il n'y aurait pas de KSH pour les développements que nous faisons, malheureusement, ce n'est pas moi qui décide et surtout KSH est bien ancré dans les mentalités (plus de 10 ans que tout est comme ça côté Unix) :)
Xavier Maillard
Rapport Cedras
NON A NICOLAS SARKOZY
NON A NICOLAS SARKOZY
[^]Re: Shell scripting
C'est les memes personnes qui utilisent encore csh ou ksh de base au lieu de bash ou zsh ? :)
A part pour gerer les fichiers eux meme, dans les repertoires, a coup de "find" ou de "for file in *", le programation shell devrait etre considere comme de la torture et banni comme tel (sauf pour les maso, il y en a toujours).
On fait bien plus propre/performant/rapidement avec Perl, Python ou Ruby.
[^]Re: Shell scripting
Bah si c'est pour faire du Perl 4, je préfère encore conserver KSH ;)
Python n'est pas près d'arriver sur nos machines, ruby, n'en parlons même pas ;)
Xavier Maillard
Rapport Cedras
NON A NICOLAS SARKOZY
NON A NICOLAS SARKOZY
[^]Re: Shell scripting
Perso, ma gestion des erreurs dans les scripts se résume souvent à terminer dès qu'un truc non supporté se passe. J'ai pris, avec les ebuilds Gentoo, l'habitude de faire des "do_something || die" un peu partout. Ça coute rien, ça alourdi pas le code, donc faut pas se priver. J'ai souvent aussi des espèces d'asserts du genre :
[[ -n $foo ]] || die "\$foo aurait déjà due être définie à ce stade"
Pour des scripts courts, mon implem' de die() se résume à une ligne de ce style :
die() { [[ $# -gt 0 ]] && echo "!!! $*" >&2 ; exit 1 ; }
Pour des scripts plus tordus, je m'adapte une des bonnes implèm' existantes, comme celle là (affiche une stack trace, et flingue le processus principal quand je die depuis un sous-shell) :
http://paludis.pioto.org/trac/browser/trunk/paludis/reposito(...)
Ne pas oublier un petit shopt -s expand_aliases puisque cette implem' utilise des aliases. Et attention, là on est dans du Bash, et déjà assez loin d'un shell Posix quelconque.