Gestion des erreurs

6 minutes

Jusqu’à présent, vous avez vu comment l’ajout de paramètres et les constructions de contrôle du flux peuvent rendre vos scripts flexibles et plus sûrs à utiliser. Toutefois, vous obtenez parfois des erreurs dans vos scripts. Vous avez besoin d’un moyen de traiter ces erreurs.

Voici quelques facteurs à prendre en compte :

Comment gérer l’erreur. Parfois, vous recevez des erreurs à partir desquelles vous pouvez récupérer et, parfois, il est préférable d’arrêter le script. Il est important de réfléchir aux types d’erreurs qui peuvent se produire et à la manière de les gérer au mieux.
La gravité de l’erreur. Il existe différents types de messages d’erreur. Certains ressemblent plus à des avertissements indiquant à l’utilisateur que quelque chose ne va pas. Certains sont plus graves et l’utilisateur doit vraiment y prêter attention. Votre approche de la gestion des erreurs dépend du type d’erreur. L’approche peut aller de l’affichage d’un message à l’augmentation du niveau de gravité, voire éventuellement à l’arrêt du script.

Erreurs

Une applet de commande ou une fonction, par exemple, peut générer de nombreux types d’erreurs. Nous vous recommandons d’écrire du code pour gérer chaque type d’erreur susceptible de se produire, et de les gérer de manière appropriée en fonction de leur type. Par exemple, supposons que vous essayiez d’écrire dans un fichier. Vous pouvez recevoir différents types d’erreurs, en fonction de ce qui ne va pas. Si vous n’êtes pas autorisé à écrire dans ce fichier, vous pouvez obtenir un certain type d’erreur. Si le fichier n’existe pas, vous pouvez obtenir un autre type d’erreur, etc.

Il existe deux types d’erreur que vous pouvez obtenir quand vous exécutez PowerShell :

Erreur avec fin d’exécution. Une erreur de ce type arrêtera l’exécution à la ligne où l’erreur est survenue. Vous pouvez traiter ce type d’erreur en utilisant Try-Catch ou Trap. Si cette erreur n’est pas traitée, le script se ferme à ce stade et aucune instruction ne s’exécutera.

Notes

La construction Trap dépasse le cadre de ce module. Si cela vous intéresse, consultez À propos de Trap.
Erreur sans fin d’exécution. Ce type d’erreur indique à l’utilisateur que quelque chose ne va pas, mais le script se poursuit. Vous pouvez mettre à niveau ce type d’erreur en une erreur avec fin d’exécution.

Gestion des erreurs à l’aide de `Try/Catch/Finally`

Vous pouvez considérer une erreur avec fin d’exécution comme une erreur inattendue. Ces erreurs sont graves. Quand vous en rencontrez une, vous devez déterminer son type d’erreur et la marche à suivre.

Trois constructions associées peuvent vous aider à gérer ce type d’erreur :

Try. Vous utilisez un bloc Try pour encapsuler une ou plusieurs instructions. Vous placez le code que vous souhaitez exécuter, par exemple, du code pour écrire dans une source de données, entre accolades. Un bloc Try doit contenir au moins un bloc Catch ou Finally. Voici à quoi cela ressemble :
```
Try {
   # Statement. For example, call a command.
   # Another statement. For example, assign a variable.
}
```
Catch. Ce mot clé vous permet d’intercepter ou de gérer une erreur lorsqu’elle se produit. Vous examinez alors l’objet exception pour déterminer quel type d’erreur s’est produit, l’endroit où il s’est produit et si le script peut récupérer. Un bloc Catch suit immédiatement un bloc Try. Vous pouvez inclure plus d’un Catch, un pour chaque type d’erreur, si vous le souhaitez. Voici un exemple :
```
Try {
   # Do something with a file.
} Catch [System.IO.IOException] {
   Write-Host "Something went wrong"
}  Catch {
   # Catch all. It's not an IOException but something else.
}
```
Le script tente d’exécuter une commande qui effectue un travail d’E/S. Le premier bloc Catch intercepte un type spécifique d’erreur : [System.IO.IOException]. Le dernier bloc Catch intercepte tout ce qui n’est pas un type [System.IO.IOException].
Finally. Les instructions de ce bloc s’exécutent, qu’un problème se manifeste ou non. Vous n’utiliserez probablement pas souvent ce bloc, mais il peut être utile pour nettoyer des ressources, par exemple. Pour l’utiliser, ajoutez-le comme dernier bloc :
```
Try {
   # Do something with a file.
} Catch [System.IO.IOException] {
   Write-Host "Something went wrong"
}  Catch {
   # Catch all. It's not an IOException but something else.
} Finally {
   # Clean up resources.
}
```

Inspection des erreurs

Nous avons abordé les objets d’exception dans le contexte de l’interception des erreurs. Vous pouvez utiliser ces objets pour inspecter les problèmes et prendre les mesures appropriées. Un objet d’exception contient :

Un message. Le message vous indique en quelques mots le problème.
La trace d’appels. La trace d’appels vous indique les instructions exécutées avant l’erreur. Imaginez que vous avez un appel à la fonction A, suivie de B, suivie de C. Le script cesse de répondre à C. La trace d’appels affiche cette chaîne d’appels.
La ligne incriminée. L’objet d’exception vous indique également quelle ligne le script exécutait quand l’erreur est survenue. Cette information peut vous aider à déboguer votre code.

Comment inspecter un objet d’exception ? Il existe une variable intégrée, $_, qui possède une propriété exception. Pour obtenir le message d’erreur, par exemple, utilisez $_.exception.message. En programmation, cela peut se présenter comme suit :

Try {
     # Do something with a file.
   } Catch [System.IO.IOException] {
     Write-Host "Something IO went wrong: $($_.exception.message)"
   }  Catch {
     Write-Host "Something else went wrong: $($_.exception.message)"
   }

Génération d’erreurs

Dans certains cas, vous pouvez être amené à générer une erreur :

Erreurs sans fin d’exécution. Pour ce type d’erreur, PowerShell vous avertit simplement qu’un problème s’est produit, en utilisant l’applet de commande Write-Error, par exemple. Le script continue à s’exécuter. Ce n’est peut-être pas le comportement que vous souhaitez. Pour augmenter la gravité de l’erreur, vous pouvez utiliser un paramètre comme -ErrorAction pour générer une erreur qui peut être interceptée avec Try/Catch, comme suit :
```
Try {
   Get-Content './file.txt' -ErrorAction Stop
} Catch {
   Write-Error "File can't be found"
}
```
En utilisant le paramètre -ErrorAction et la valeur Stop, vous pouvez provoquer une erreur qui peut être interceptée par Try/Catch.
Règles métier. Vous pouvez rencontrer une situation où le code ne cesse pas réellement de répondre, bien que vous le souhaitiez pour des raisons professionnelles. Supposons que vous assainissiez l’entrée et que vous vérifiiez si un paramètre est un chemin d’accès. Un besoin métier peut spécifier que seuls certains chemins d’accès sont autorisés ou que le chemin d’accès doit avoir un aspect spécifique. Si les vérifications échouent, il est logique de générer une erreur. Dans une situation comme celle-ci, vous pouvez utiliser un bloc Throw :
```
Try {
   If ($Path -eq './forbidden') 
   {
     Throw "Path not allowed"
   }
   # Carry on.

} Catch {
   Write-Error "$($_.exception.message)" # Path not allowed.
}
```
Notes

En général, n’utilisez pas Throw pour la validation de paramètres. Utilisez des attributs de validation à la place. Si vous ne pouvez pas faire fonctionner votre code avec ces attributs, un Throw peut faire l’affaire.

Rétroaction

Cette page vous a-t-elle été utile ?