La problématique du déboguage est la suivante: j'ai un utilitaire qui plante au milieu de la pipeline et je veux comprendre pourquoi. Je veux donc accéder à:
La ligne d'appel de l'utilitaire (argument vector)
L'environnement du processus
Son dossier d'exécution
Le code de retour
Le contenu de stdout
Le contenu de stderr.
Si je lance la commande rm ou cp je n'ai peut-être pas besoin d'avoir accès à tous ces détails pour comprendre ce qui s'est mal passé, mais dans les cas de programmes complexes, comme par exemple un compilateur, TeX ou METAPOST, accéder à ces informations est primordial.
Pour la gestion des erreurs, imaginons que j'ai un traitement complexe à effectuer, et qu'au milieu j'ai une erreur. Par exemple j'exécute un script par SSH sur 50 serveurs et le script plante sur deux serveurs. Je peux vouloir que mon programme supervisant l'exécution des scripts me donne la chance de voir ce qui ne va pas sur les deux serveurs puis de réessayer les scripts, et si tout s'est bien passé de continuer le pipeline. Si tout ce que me propose mon programme de supervision c'est d'arrêter le traitement à la première erreur, de nettoyer à la main le bazar qu'il a laissé derrière lui et de tout reprendre depuis zéro... et bien j'aime autant programmer directement en shell.
[^] # Re: Gestion des erreurs
Posté par Michaël (site web personnel) . En réponse au journal chaintools, outils unix avec syntaxe pythonique. Évalué à 3.
La problématique du déboguage est la suivante: j'ai un utilitaire qui plante au milieu de la pipeline et je veux comprendre pourquoi. Je veux donc accéder à:
Si je lance la commande rm ou cp je n'ai peut-être pas besoin d'avoir accès à tous ces détails pour comprendre ce qui s'est mal passé, mais dans les cas de programmes complexes, comme par exemple un compilateur, TeX ou METAPOST, accéder à ces informations est primordial.
Pour la gestion des erreurs, imaginons que j'ai un traitement complexe à effectuer, et qu'au milieu j'ai une erreur. Par exemple j'exécute un script par SSH sur 50 serveurs et le script plante sur deux serveurs. Je peux vouloir que mon programme supervisant l'exécution des scripts me donne la chance de voir ce qui ne va pas sur les deux serveurs puis de réessayer les scripts, et si tout s'est bien passé de continuer le pipeline. Si tout ce que me propose mon programme de supervision c'est d'arrêter le traitement à la première erreur, de nettoyer à la main le bazar qu'il a laissé derrière lui et de tout reprendre depuis zéro... et bien j'aime autant programmer directement en shell.