web-dev-qa-db-fra.com

Équivalent de HttpResponseException / IHttp Action Response pour .net Core web api 2 (pas mvc)

Lorsque je lis sur webapi pour répondre aux demandes et gérer les erreurs, tout est basé sur:

IHttpActionResult
HttpResponseException

Mais lorsque vous créez un projet webapi de base .net, ceux-ci ne sont pas disponibles. Je peux trouver IActionResult, qui semble être l'équivalent?

Mais je tourne en rond en essayant de découvrir une chose vraiment très simple, qui est de savoir comment gérer les erreurs dans une webapi de base .net car HttpResponseException n'est pas disponible. J'ai l'impression que tout avec 'http' dedans, c'est juste pour une application MVC complète.

Tout ce que je veux faire, c'est retourner une erreur, ça doit sûrement être simple ...

c#asp.net-coreasp.net-core-webapi
21
Neil Walker

IActionResult est l'équivalent de IHttpActionResult, comme vous l'avez suggéré. Cela fait partie de la consolidation de ce qui était connu comme MVC et API Web dans ASP.NET Core MVC.

Quant à HttpResponseException, il a été complètement supprimé dans ASP.NET Core. Il y a un issue intéressant à ce sujet sur GitHub, où David Fowler explique pourquoi c'est le cas:

Juste le paradigme "nous ne voulons pas que les gens utilisent des exceptions pour le flux de contrôle". Les gens ont fait des choses comme l'utiliser à partir de leur logique métier, ce qui est une erreur. Je ne peux pas parler des problèmes de performances parce que je n'ai pas mesuré, mais lancer une exception qui est censée être interceptée pour obtenir des données est pire que de simplement renvoyer ce résultat.

L'alternative suggérée est d'utiliser les différentes implémentations IActionResult pour créer des réponses JSON, renvoyer des erreurs, etc. Encore une fois, à partir du problème:

Ma suggestion serait que la méthode d'action retourne IActionResult (ou la variante asynchrone).

La raison pour laquelle IActionResult et object sont pris en charge est qu'ils conviennent chacun à des fins différentes et à des styles différents. Pour certains des cas les plus simples, il est agréable d'utiliser un objet, mais il n'est pas du tout puissant. Pour un contrôle total, il y a IActionResult, qui suit le "modèle de commande" bien connu.

Le modèle IActionResult permet au contrôleur d'indiquer explicitement ce qui doit se produire à la suite de l'action: une sorte de code d'erreur, une redirection, un objet de données sérialisé, une vue rendue, etc.

Si vous cherchez à gérer les erreurs en dehors des contrôleurs, vous pourriez bénéficier de la lecture de docs sur cette rubrique, qui rentre dans les détails de l'utilisation de middleware ou de filtres pour la gestion des erreurs. Dans les commentaires, il y a un lien vers un tutoriel qui explique certains aspects de la gestion des erreurs plus en détail.

Pour être complet, voici le code du tutoriel pour l'approche middleware:

app.UseExceptionHandler(
 options => {
    options.Run(
    async context =>
    {
      context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
      context.Response.ContentType = "text/html";
      var ex = context.Features.Get<IExceptionHandlerFeature>();
      if (ex != null)
      {
        var err = $"<h1>Error: {ex.Error.Message}</h1>{ex.Error.StackTrace }";
        await context.Response.WriteAsync(err).ConfigureAwait(false);
      }
    });
 }
);

Il y a aussi plus de détails sur l'approche IExceptionFilter, mais je ne rendrai pas cette réponse plus grande qu'elle ne l'est déjà.

28
Kirk Larkin