Editions ENI Livres | Vidéos | e-Formations
Gestion des erreurs et débogage
Introduction à la gestion des erreurs et au débogage
Dans votre vie de scripteur, vous serez tôt ou tard confronté aux erreurs ou plus précisément à la gestion des erreurs à l’intérieur de vos scripts. Quoi de plus rageant qu’un script qui plante en cours d’exécution ? Lorsque cela arrive, il est préférable et plus élégant d’intercepter les erreurs afin d’afficher un joli message personnalisé plutôt que de laisser PowerShell afficher ses propres messages.
D’autre part, il peut être intéressant d’essayer d’anticiper les erreurs afin d’agir en conséquence. Par exemple, si vous essayez de supprimer une arborescence complète de fichiers et que pour une raison quelconque celle-ci contient un fichier sur lequel vous n’avez pas les permissions adéquates, alors une erreur sera générée.
Grâce à ce que vous allez apprendre dans ce chapitre, vous allez pouvoir faire en sorte de décider comment PowerShell devra se comporter face aux erreurs. Devra-t-il interrompre l’exécution du script ou bien continuer ? Et s’il continue doit-il ou non afficher un message d’erreur ? Si oui, quel type de message ? Celui par défaut ou un message que vous aurez défini vous-même ?
L’autre volet de la gestion...
La gestion des erreurs
Pour bien aborder ce sujet, il nous faut tout d’abord distinguer deux types d’erreurs : les erreurs critiques (« Terminating errors » est le terme anglais correspondant) et les erreurs non critiques (« Non-Terminating errors » en anglais).
Les premières sont considérées comme graves, et lorsqu’elles surviennent l’exécution de la commande ou du script est interrompue. Les erreurs critiques se rencontrent généralement avec une erreur de syntaxe, une division par zéro, ou autres.
Les secondes, les erreurs non critiques, sont plutôt considérées comme des avertissements ; la plupart des erreurs sont généralement de ce type. Dans ce cas, l’exécution du script continue et - sauf indication contraire - les erreurs sont affichées à l’écran. On peut rencontrer ce type d’erreur, par exemple, lors de la suppression d’un fichier si les droits d’accès sont insuffisants ou si l’on cherche à déplacer un fichier qui n’existe pas.
Nous verrons que le comportement par défaut, qui consiste à continuer l’exécution d’un script lorsqu’une erreur non critique est rencontrée, peut être modifié. Car dans certains cas, il peut être préférable d’arrêter le déroulement...
Les erreurs non critiques
Il faut savoir que PowerShell permet de définir son comportement face aux erreurs de plusieurs façons :
-
Globalement : c’est-à-dire pour tout le script ou pour l’étendue en cours (cf. chapitre Variables et types de données) grâce à la variable de préférence $ErrorActionPreference.
-
Sélectivement : c’est-à-dire que pour chaque commandelette le comportement peut différer. Ceci est rendu possible grâce à l’utilisation d’un paramètre qui est commun à toutes les commandes. Ce paramètre se nomme -ErrorAction.
1. Variable de préférence : $ErrorActionPreference
Intéressons-nous pour l’instant à la « variable de préférence » (c’est ainsi qu’on appelle les variables qui stockent les préférences des utilisateurs) $ErrorActionPreference.
Elle peut prendre les valeurs suivantes :
|
Valeur |
Description |
|
SilentlyContinue |
Le script s’exécute sans afficher d’erreur même s’il en rencontre. |
|
Continue |
Le script continue s’il rencontre une erreur et l’affiche (valeur par défaut). |
|
Stop |
Le script s’interrompt s’il rencontre une erreur. Dans ce cas toutes les erreurs deviennent des erreurs critiques. |
|
Inquire |
Lorsqu’une erreur survient, un prompt demande à l’utilisateur ce qu’il doit faire (continuer, continuer en mode silencieux, arrêter ou suspendre). |
|
Ignore |
Même comportement que SilentlyContinue excepté qu’en cas d’erreur celle-ci n’est pas stockée dans la variable automatique $Error. |
Comme par défaut $ErrorActionPreference contient la valeur Continue, les erreurs non critiques ne sont pas bloquantes ; elles sont seulement consignées par PowerShell et affichées à l’écran.
Lorsque $ErrorActionPreference prend la valeur Stop, toutes les erreurs rencontrées deviennent des erreurs critiques. Ainsi, une erreur non critique apparaissant durant l’exécution d’un script interrompra ce dernier, exactement à la manière d’une erreur critique. Pour modifier la valeur de $ErrorActionPreference, vous pouvez faire ceci $ErrorActionPreference = ’Stop’ (n’oubliez pas les guillemets !) ou Set-Variable...
Les erreurs critiques
Partons à présent à la chasse aux erreurs critiques, appelées couramment « exceptions » chez les développeurs. C’est donc ainsi que nous les appellerons afin de les distinguer des erreurs non critiques.
Grâce à ce que nous allons découvrir dans cette partie, nous aurons encore plus de maîtrise sur nos scripts. Ainsi, plutôt que de voir un script s’arrêter brutalement à cause d’une exception, nous allons pouvoir agir en conséquence et prendre les mesures (correctives ou alternatives) qui s’imposent. En effet, il est souvent indispensable de savoir si tout s’exécute normalement. Mais pour cela, il va nous falloir essayer de prévoir les erreurs avant qu’elles ne se produisent...
1. Interception des erreurs critiques avec Try-Catch-Finally
Comme nous le disions précédemment, lorsqu’une erreur critique survient, l’exécution s’interrompt brusquement. Pour éviter d’avoir à gérer les erreurs commande par commande, nous pouvons utiliser des blocs d’exécution Try, Catch et Finally. Ces instructions sont bien connues car présentes dans de nombreux langages de programmation.
Le bloc Try contient le code risquant de provoquer l’exception. Il est exécuté jusqu’à la levée d’une exception (exemple : division par zéro) ou jusqu’à sa réussite totale. Si une erreur critique se produit pendant l’exécution des instructions, PowerShell passe l’objet erreur du bloc Try au bloc Catch.
La syntaxe du bloc Try est la suivante :
Try {<bloc d'instructions>}
La clause Catch contient le bloc d’exécution associé optionnellement au type d’erreur à intercepter. Lorsque Catch est utilisée sans préciser de type, toute exception est interceptée. La syntaxe du bloc Catch est la suivante :
Catch [<type d'erreur à intercepter>] {<bloc d'instructions>}
Optionnel, Finally s’utilise suivi d’un bloc de script. Ce dernier s’exécute chaque fois que le script...
Le débogage
PowerShell, côté débogage, est doté de riches fonctionnalités par rapport à son cousin VBScript. Et cela est d’autant plus vrai qu’il intègre la notion de point d’arrêt et d’exécution pas à pas en mode console ainsi que de façon graphique.
Il y a mille et une façons de déboguer un programme ; cela pourrait presque s’assimiler à de l’art tellement parfois cela peut s’avérer complexe et par conséquent chronophage. Et bien souvent, les techniques diffèrent d’une personne à l’autre. Cependant, les bases restent… Une technique des plus classiques consiste à intercaler dans un script des affichages de variables ou de messages ici et là pour essayer de trouver les bugs. Nous verrons qu’avec PowerShell nous pouvons faire mieux que placer des Write-Host de débogage un peu partout et ainsi « polluer » notre code.
Nous vous montrerons également dans cette partie comment faire de l’exécution pas à pas, souvent indispensable pour trouver l’origine de nos erreurs.
Enfin, pour éviter de perdre du temps à déboguer, le mieux est d’éviter de créer des bugs. Facile à dire, nous direz-vous ! Vous verrez qu’en vous efforçant de respecter quelques bonnes pratiques, telles que déclarer vos variables et leur donner un type, vous gagnerez un temps précieux. Nous en parlerons également.
1. Affichage d’informations durant l’exécution
PowerShell est doté de plusieurs flux de messages qui ne sont pas actifs par défaut. Ces différents types de messages peuvent s’avérer très utiles lorsque l’on pratique le débogage (mais pas seulement) car on peut les activer à la demande. On peut donc laisser ces diverses commandes dans notre code, car elles ne font rien lorsqu’elles ne sont pas activées.
En effet, dans d’autres langages que PowerShell, lorsque l’on pratique le débogage via de l’affichage (messages ou variables), nous sommes bien souvent obligés de revenir dans le code une fois la session de débogage terminée afin de mettre en commentaire chaque ligne. Ce ne sera désormais plus nécessaire...
