ASP.NET Core : Gérer les erreurs
Afficher une page d’erreur personnalisé en ASP.NET Core est très simple, mais il y a quelques pièges à éviter.
Pour afficher une page d’erreur (erreur 500) il suffit d’écrire la ligne de code suivante :
|
1
|
app.UseExceptionHandler("Error"); |
Pour afficher les autres types d’erreurs (page 404, etc…) il suffit d’appeler la méthode suivante :
|
1
|
app.UseStatusCodePagesWithRedirects("/StatusCode?code={0}"); |
Malheureusement, ce n’est pas aussi simple !
Si votre site Web ASP.NET Core héberge des WebAPI elles aussi seront affectées par ces modifications.
Exclure les API des pages d’erreurs personnalisées
Dans ces cas-là, j’ai la chance de pouvoir invoquer un magicien d’ASP.NET Core qui m’aiguille vers la solution pour gérer ces cas épineux. D’ailleurs je vous conseille fortement sa série d’article sur l’utilisation d’User defined function avec EF Core.
Modifier la gestion des StatusCode
Pour modifier l’affichage de la page gérant les StatusCode il faudra donc passer un StatusCodePagesOptions et exclure toute les routes qui commencent par “api”.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
app.UseStatusCodePages(new StatusCodePagesOptions(){ HandleAsync = ctx => { if (ctx.HttpContext.Request.Path != null && !ctx.HttpContext.Request.Path.Value.StartsWith("api")) { ctx.HttpContext.Response.Redirect($"/StatusCode?code={ctx.HttpContext.Response.StatusCode}"); return Task.CompletedTask; } return ctx.Next.Invoke(ctx.HttpContext); }}); |
Modifier la gestion des erreurs
Pour la gestion des erreurs nous utiliserons les même logique, tous les segments commençant par api seront exclu.
A noter : que nous utilisons la méthode UseWhen qui permet d’utiliser un middleware uniquement dans certains cas.
|
1
2
|
app.UseWhen(ctx => !ctx.Request.Path.StartsWithSegments("/api", StringComparison.OrdinalIgnoreCase), cfg => cfg.UseExceptionHandler("/Error"));
|
Happy coding 🙂
Pour aller plus loin :
Commentaires