Adam the Automator (Français)

avez – vous déjà exécuté un script ou une applet de commande PowerShell et Êtes – vous confronté à un mur de texte criant-en rouge-comme celui illustré ci-dessous?

Exemple d’erreurs dans PowerShell

les Erreurs peuvent devenir écrasante et déroutant. Et surtout, les erreurs sont souvent difficiles à lire, ce qui rend presque impossible de déterminer quoi et où le script a mal tourné.,

heureusement, vous avez quelques options dans PowerShell pour améliorer cela grâce à la gestion des erreurs. En utilisant la gestion des erreurs, les erreurs peuvent être filtrées et affichées de manière à ce qu’elles soient plus faciles à comprendre. De plus, la compréhension de l’erreur permet d’ajouter plus de logique à la gestion des erreurs.

dans cet article, vous découvrirez les erreurs dans PowerShell et comment elles peuvent être interceptées pour effectuer une gestion des erreurs à l’aide des blocs PowerShell Try Catch (Et finally).,

Table des Matières

Comprendre Comment les Erreurs de Travailler dans PowerShell

Avant de plonger dans la gestion d’erreur, nous allons tout d’abord aborder quelques concepts autour d’erreurs dans PowerShell. Comprendre les erreurs peut conduire à de meilleures stratégies de gestion des erreurs.

la Variable automatique Error Error

dans PowerShell, il y a beaucoup de variables automatiques, et l’une d’entre elles est la variable automatique$Error. PowerShell utilise la variable$Error pour stocker toutes les erreurs rencontrées dans la session., La variable$Error est un tableau d’erreurs triées par la plus récente.

lorsque vous ouvrez une session PowerShell pour la première fois, la variable$Error est vide. Vous pouvez le vérifier en appelant la variable$Error.

Le $Erreur variable est vide

Comme vous pouvez le voir, la balise $Error variable commence à vide., Mais, une fois qu’une erreur est générée, l’erreur sera ajoutée et stockée dans la variable $Error.

dans l’exemple ci-dessous, l’erreur est générée en obtenant délibérément un nom de service qui n’existe pas.

PS> Get-Service xyzPS> $ErrorPS> $Error.Count
L’erreur est ajouté à l’ $variable d’Erreur

Comme vous pouvez le voir à partir de la sortie ci-dessus, l’erreur générée a été ajouté à la balise $Error variable.,

Le $variable d’Erreur contient une collection d’erreurs générées dans la session PowerShell. Chaque erreur peut être access en appelant sa position de tableau. La dernière erreur sera toujours à l’indice 0.

Par exemple, la dernière erreur peut être récupérée en utilisant $Error.

les propriétés de L’objet Error Error

puisque tout dans PowerShell est un objet, la variable$Error est un objet et les objets ont des propriétés., En raccordant la variable$Error à l’applet de commandeGet-Member, vous devriez voir la liste des propriétés disponibles.

$Error | Get-Member
Le $Erreur propriétés de l’objet

Pour déterminer la cause de l’erreur, vous pouvez afficher le contenu de la balise InvocationInfo propriété à l’aide de la commande ci-dessous.,

$Error.InvocationInfo
Le InvocationInfo propriété

Maintenant, vous pouvez faire de même avec les autres propriétés et découvrir ce que les autres informations que vous pouvez trouver!

erreurs de terminaison

les erreurs de terminaison arrêtent le flux d’exécution lorsqu’il est rencontré par des erreurs PowerShell vs non terminatrices. Une erreur de terminaison peut se produire de plusieurs façons. Un exemple est lorsque vous appelez une applet de commande avec un paramètre qui n’existe pas.,

comme vous le verrez dans la capture d’écran ci-dessous, lorsque la commandeGet-Process notepad s’exécute, la commande est valide et les détails du processus du bloc-notes sont affichés.

Le processus de bloc-notes détails

Mais, lorsqu’un paramètre qui n’existe pas est utilisé comme Get-Process notepad -handle 251, l’applet de commande affiche un message d’erreur que le handle paramètre n’est pas valide. Ensuite, l’applet de commande se termine sans afficher les détails du processus notepad.,

erreur est levée parce que le paramètre est invalide

erreurs de non-terminaison

les erreurs de non-terminaison sont des erreurs qui n’arrêtent pas l’exécution du script ou de la commande. Par exemple, consultez le code ci-dessous. Ce code obtient la liste des noms de fichiers de la liste de fichiers.fichier txt. Ensuite, le script parcourt chaque nom de fichier, lit le contenu de chaque fichier et le sort à l’écran.

$file_list = Get-Content .\filelist.txtforeach ($file in $file_list) { Write-Output "Reading file $file" Get-Content $file}

Le contenu de la liste de fichiers.,fichier txt sont les noms de fichiers montre dans la liste ci-dessous.

File_1.logFile_2.logFile_3.logFile_4.logFile_5.logFile_6.logFile_7.logFile_8.logFile_9.logFile_10.log

Mais Que faire si File_6.log n’existait pas réellement? Lorsque vous exécutez le code, vous vous attendez à ce qu’une erreur se produise car le script ne peut pas trouver le Fichier_6.journal. Vous verrez une sortie similaire ci-dessous.

exemple d’erreur de non-terminaison

comme vous pouvez le voir sur la capture d’écran du résultat ci-dessus, le script a pu lire les cinq premiers fichiers dans la liste, mais quand il a essayé de lire le fichier file_6.,txt, une erreur est renvoyée. Le script a ensuite continué à lire le reste des fichiers avant de quitter. Il n’a pas de fin.

la Variable er ErrorActionPreference

Jusqu’à présent, vous avez appris les erreurs terminantes et non terminantes et comment elles diffèrent les unes des autres. Mais saviez-vous qu’une erreur de non-terminaison peut être forcée d’être traitée comme une erreur de terminaison?

PowerShell a un concept appelé variables de préférence. Ces variables sont utilisées pour modifier le comportement de PowerShell de différentes manières. Une de ces variables est appelée $ErrorActionPreference.,

la variable $ErrorActionPreference est utilisée pour modifier la façon dont PowerShell traite les erreurs non terminantes. Par défaut, la valeur$ErrorActionPreference est définie surContinue. Changer la valeur de la variable $ErrorActionPreference en STOPforce PowerShell à traiter toutes les erreurs comme des erreurs de fin.

Utilisez le code ci-dessous pour modifier la balise $ErrorActionPreference valeur.,

$ErrorActionPreference = "STOP"

pour en savoir plus sur les autres valeurs de variable valid ErrorActionPreference valides, visitez PowerShell ErrorActionPreference.

maintenant, reportez-vous à l’exemple utilisé dans la section Erreurs Non terminantes de cet article. Le script peut être modifié pour inclure le changement dans $ErrorActionPreference comme le code ci-dessous:

L’exécution du code modifié ci-dessus se comportera différemment qu’auparavant lorsque la valeur$ErrorActionPreferenceest définie sur la valeur par défaut deContinue.,

forçant une erreur de fin en utilisant la variable$ErrorActionPreference

comme vous pouvez le voir sur la capture d’écran du résultat ci-dessus, le script a pu lire les cinq premiers fichiers de la liste, mais quand il a essayé de lire le fichier file_6.txt, une erreur est renvoyée car le fichier n’a pas été trouvé. Ensuite, le script s’est terminé et le reste des fichiers ne sont pas lus.,

la valeur $ErrorActionPreference n’est valide que dans la session PowerShell en cours. Il se réinitialise à la valeur par défaut une fois qu’une nouvelle session PowerShell est démarrée.

le paramètre commun ErrorAction

Si la valeur$ErrorActionPreference est appliquée à la session PowerShell, le paramètreErrorAction s’applique à toute applet de commande prenant en charge les paramètres communs. Le paramètreErrorAction accepte les mêmes valeurs que la variable$ErrorActionPreference.,

Le ErrorAction valeur du paramètre est prioritaire sur le $ErrorActionPreference valeur.

revenons en arrière et utiliser le même code dans l’exemple précédent. Mais, cette fois, le paramètre ErrorAction est ajouté à la ligne Get-Content.

Après avoir exécuté le code modifié, vous verrez que même si$ErrorActionPreferenceest défini surContinue, le script s’est toujours terminé une fois qu’il a rencontré une erreur., Le script est terminé car la balise -ErrorAction valeur du paramètre Get-Content est réglé sur STOP.

forçant une erreur de fin en utilisant leErrorAction paramètre

utilisation de PowerShell try catch blocks

à ce stade, vous avez appris les erreurs PowerShell et le fonctionnement des paramètres$ErrorActionPreference etErrorAction., Maintenant, il est temps d’en apprendre davantage sur les bonnes choses – les blocs PowerShell Try Catch Finally.

PowerShelltry catch les blocs (et optionnelsfinally block) sont un moyen de lancer un réseau autour d’un morceau de code et d’attraper les erreurs qui reviennent.

le code ci-dessous montre la syntaxe de l’instructionTry.

try { <statement list>}catch *]{ <statement list>}finally { <statement list>}

Le Try bloc contient le code que vous souhaitez PowerShell pour « essayer” et vérifier les erreurs., Si le code du blocTry rencontre une erreur, l’erreur est ajoutée à la variable$Error, puis transmise au blocCatch.

le blocCatchcontient les actions à exécuter lorsqu’il reçoit une erreur du blocTry. Il peut y avoir plusieurs Catch blocs dans un Try déclaration.

le blocFinallycontient le code qui sera à la fin de l’instructionTry., Ce bloc s’exécute si une erreur a été innombrables.

la Capture de Non-Spécifiques des Erreurs (Fourre-Tout)

Un simple Try déclaration contient un Try et un Catch bloc. Le blocFinally est facultatif.

par exemple, pour intercepter une exception non spécifique, le paramètre Catch doit être vide. L’exemple de code ci-dessous utilise le même script qui a été utilisé dans la section Variable The ErrorActionPreference mais modifié pour utiliser les blocs Try Catch.,

comme vous pouvez le voir dans le code ci-dessous, cette fois, l’instructionforeachest incluse dans le blocTry. Ensuite, un blocCatch contient le code pour afficher la chaîneAn Error Occurred en cas d’erreur. Le code dans le bloc Finally efface simplement la variable $Error.

le code ci-dessus, après l’exécution dans PowerShell, vous donnera cette sortie ci-dessous.,

Script terminé lorsqu’une erreur s’est produite

La sortie ci-dessus montre que le script a rencontré une erreur, couru le code à l’intérieur de la balise Catch bloc, et puis terminé.

l’erreur a été gérée, ce qui était le point de gestion des erreurs. Cependant, l’erreur affichée était trop générique. Pour afficher une erreur plus descriptive, vous pouvez accéder à la propriétéException de l’erreur transmise par le blocTry.,

le code ci – dessous est modifié, en particulier le code à l’intérieur du blocCatch, pour afficher le message d’exception de l’erreur actuelle transmise dans le pipeline – $PSItem.Exception.Message

Cette fois, lorsque le code modifié ci-dessus est exécuté, le message affiché est beaucoup plus descriptif.,

Script termine avec un message d’erreur descriptif

la Capture des Erreurs

Il ya des moments où un fourre-tout de la gestion d’erreur n’est pas l’approche la plus appropriée. Peut-être souhaitez-vous que votre script effectue une action qui dépend du type d’erreur rencontré.

comment déterminez-vous le type d’erreur? En vérifiant la valeur TypeName de la propriété Exception de la dernière erreur., Par exemple, pour trouver le type d’erreur de l’exemple précédent, utilisez cette commande:

$Error.Exception | Get-Member

le résultat du code ci-dessus ressemblerait à la capture d’écran ci-dessous. Comme vous pouvez le voir, la balise TypeName valeur est affichée – System.Management.Automation.ItemNotFoundException.

l’Obtention de l’erreur TypeName valeur

Maintenant que vous savez le type d’erreur que vous avez besoin d’intercepter, de modifier le code afin de l’attraper en particulier., Comme vous le voyez dans le code modifié ci-dessous, il y a maintenant deux blocs Catch. Le premier blocCatch intercepte un type d’erreur spécifique (System.Management.Automation.ItemNotFoundException). En revanche, le deuxième blocCatch contient le message d’erreur générique fourre-tout.

la capture d’écran ci-dessous montre la sortie du code modifié ci-dessus.,

Script termine avec un message d’erreur spécifique

Conclusion

Dans cet article, vous avez appris à propos des erreurs dans PowerShell, ses propriétés, et comment vous pouvez déterminer une erreur de type spécifique. Vous avez également appris la différence entre la variable$ErrorActionPreference et le paramètreErrorAction affecte la façon dont PowerShell traite les erreurs non terminantes.,

Vous avez également appris à utiliser les blocs PowerShellTry Catch Finally pour gérer les erreurs, que ce soit pour des erreurs spécifiques ou une approche fourre-tout.

Les exemples présentés dans cet article ne montrent que les bases du fonctionnement des blocs Try Catch Finally. Les connaissances que j’espère que vous avez acquises dans cet article devraient vous donner les blocs de départ pour commencer à appliquer la gestion des erreurs dans vos scripts.,

Lecture

  • About_Try_Catch_Finally
  • About_Automatic_Variables
  • Retour à l’essentiel: Le PowerShell Boucle foreach
  • Retour à l’essentiel: la Compréhension de PowerShell Objets

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *