Interpréter les actions d’erreur pour les commandes Windows PowerShell
Quand une commande PowerShell génère une erreur, il peut s’agir d’une erreur avec fin d’exécution ou d’une erreur sans fin d’exécution. Une erreur avec fin d’exécution se produit lorsque Windows PowerShell détermine qu’il n’est pas possible de poursuivre le traitement après l’erreur, et que la commande s’arrête. Une erreur sans fin d’exécution se produit lorsque Windows PowerShell détermine qu’il est possible de poursuivre le traitement après l’erreur. Quand une erreur sans fin d’exécution se produit, le script ou le pipeline en cours continue de s’exécuter. Les erreurs sans fin d’exécution sont plus courantes que les erreurs avec fin d’exécution.
Prenez la commande suivante :
Get-WmiObject -Class Win32_BIOS -ComputerName LON-SVR1,LON-DC1
Si vous supposez que l’ordinateur LON-SVR1 n’est pas disponible sur le réseau, la cmdlet Get-WmiObject génère une erreur quand elle tente d’interroger cet ordinateur. Toutefois, la commande pourrait continuer avec l’ordinateur suivant, LON-DC1. L’erreur est donc une erreur sans fin d’exécution.
$ErrorActionPreference
Windows PowerShell a une variable globale intégrée nommée $ErrorActionPreference. Quand une commande génère une erreur sans fin d’exécution, elle vérifie cette variable pour déterminer ce qu’il convient de faire. La variable peut avoir l’une des quatre valeurs :
- Continue : valeur par défaut indiquant à la commande d’afficher un message d’erreur et de continuer à s’exécuter.
- SilentlyContinue : indique à la commande de n’afficher aucun message d’erreur et de continuer à s’exécuter.
- Inquire : indique à la commande d'afficher une invite demandant à l'utilisateur quoi faire.
- Stop : indique à la commande de traiter l’erreur comme une erreur avec fin d’exécution et donc d’arrêter l’exécution.
Pour définir la variable $ErrorActionPreference, utilisez la syntaxe suivante :
$ErrorActionPreference = 'Inquire'
Remarque
Soyez sélectif en lien avec l’utilisation de SilentlyContinue pour $ErrorActionPreference. Vous pouvez penser que cela améliore votre script pour les utilisateurs, mais cela peut compliquer la résolution des problèmes.
Si vous envisagez d’intercepter une erreur dans votre script afin de pouvoir la gérer, les commandes doivent utiliser l’action Stop. Vous ne pouvez intercepter et gérer que des erreurs avec fin d’exécution.
Paramètre -ErrorAction
Toutes les commandes Windows PowerShell ont le paramètre – ErrorAction. Ce paramètre a l’alias – EA. Le paramètre accepte les mêmes valeurs que $ErrorActionPreference, et le paramètre remplace la variable pour cette commande. Si vous vous attendez à ce qu’une erreur se produise sur une commande, vous utilisez –ErrorAction pour définir l’action de cette commande en cas d’erreur sur Arrêter. Cela vous permet d’intercepter et de gérer l’erreur pour cette commande, mais laisse toutes les autres commandes utiliser l’action dans $ErrorActionPreference. Voici un exemple :
Get-WmiObject -Class Win32_BIOS -ComputerName LON-SVR1,LON-DC1 -ErrorAction Stop
L’unique situation dans laquelle vous êtes amené à modifier $ErrorActionPreference est quand vous attendez une erreur en dehors d’une commande Windows PowerShell, par exemple, lorsque vous exécutez une méthode telle que la suivante :
Get-Process –Name Notepad | ForEach-Object { $PSItem.Kill() }
Dans cet exemple, la méthode Kill() pourrait générer une erreur. Toutefois, comme il ne s’agit pas d’une commande Windows PowerShell, elle n’a pas le paramètre – ErrorAction. Au lieu de cela, définissez $ErrorActionPreference sur Stop avant d’exécuter la méthode, puis redéfinissez la valeur de la variable sur Continue une fois la méthode exécutée.