ASP.NET Web de Base de l'API de gestion des exceptions

J'ai commencé à utiliser ASP.NET de Base pour ma nouvelle API REST projet, après l'utilisation régulière ASP.NET l'API Web pour de nombreuses années. Je ne vois pas une bonne façon de gérer les exceptions dans ASP.NET de Base de l'API Web. J'ai essayé de mettre en œuvre la gestion des exceptions filtre/attribut:

public class ErrorHandlingFilter : ExceptionFilterAttribute
{
    public override void OnException(ExceptionContext context)
    {
        HandleExceptionAsync(context);
        context.ExceptionHandled = true;
    }

    private static void HandleExceptionAsync(ExceptionContext context)
    {
        var exception = context.Exception;

        if (exception is MyNotFoundException)
            SetExceptionResult(context, exception, HttpStatusCode.NotFound);
        else if (exception is MyUnauthorizedException)
            SetExceptionResult(context, exception, HttpStatusCode.Unauthorized);
        else if (exception is MyException)
            SetExceptionResult(context, exception, HttpStatusCode.BadRequest);
        else
            SetExceptionResult(context, exception, HttpStatusCode.InternalServerError);
    }

    private static void SetExceptionResult(
        ExceptionContext context, 
        Exception exception, 
        HttpStatusCode code)
    {
        context.Result = new JsonResult(new ApiResponse(exception))
        {
            StatusCode = (int)code
        };
    }
}

Et voici mon Démarrage d'enregistrement de filtre:

services.AddMvc(options =>
{
    options.Filters.Add(new AuthorizationFilter());
    options.Filters.Add(new ErrorHandlingFilter());
});

Le problème j'ai eu, c'est que lorsque exception occurres dans mon AuthorizationFilter c'est pas manipulé par ErrorHandlingFilter. Je m'attendais à être pris comme il a travaillé avec de vieux ASP.NET l'API Web.

Alors, comment puis-je attraper toutes les exceptions de l'application ainsi que toutes les exceptions de l'Action des Filtres?

  • Avez-vous essayé UseExceptionHandler middleware?
  • J'ai un exemple ici sur la façon d'utiliser UseExceptionHandler middleware
InformationsquelleAutor Andrei | 2016-07-28
  1. 418

    La Gestion Des Exceptions Middleware

    Après de nombreuses expériences avec différents exception de la manipulation des approches j'ai fini par utiliser un middleware. Il a travaillé sur le meilleur pour mon ASP.NET Web de Base de l'API de l'application. Il gère les exceptions de l'application, ainsi que les exceptions de l'action des filtres et j'ai le plein contrôle sur la gestion des exceptions et de la réponse HTTP. Voici mon traitement d'exception middleware:

    public class ErrorHandlingMiddleware
{
    private readonly RequestDelegate next;
    public ErrorHandlingMiddleware(RequestDelegate next)
    {
        this.next = next;
    }

    public async Task Invoke(HttpContext context /* other dependencies */)
    {
        try
        {
            await next(context);
        }
        catch (Exception ex)
        {
            await HandleExceptionAsync(context, ex);
        }
    }

    private static Task HandleExceptionAsync(HttpContext context, Exception ex)
    {
        var code = HttpStatusCode.InternalServerError; //500 if unexpected

        if      (ex is MyNotFoundException)     code = HttpStatusCode.NotFound;
        else if (ex is MyUnauthorizedException) code = HttpStatusCode.Unauthorized;
        else if (ex is MyException)             code = HttpStatusCode.BadRequest;

        var result = JsonConvert.SerializeObject(new { error = ex.Message });
        context.Response.ContentType = "application/json";
        context.Response.StatusCode = (int)code;
        return context.Response.WriteAsync(result);
    }
}

    Enregistrer avant MVC dans Startup classe:

    app.UseMiddleware(typeof(ErrorHandlingMiddleware));
app.UseMvc();

    Vous pouvez ajouter de la trace de la pile d'exception de type nom, les codes d'erreur ou quoi que ce soit que vous voulez il. Très flexible. Voici un exemple d'exception réponse:

    { "error": "Authentication token is not valid." }

    Injecter des IOptions<MvcJsonOptions> à la Invoke méthode pour l'utiliser ensuite lors de la sérialisation de l'objet de réponse à utiliser ASP.NET MVC de sérialisation de paramètres dans JsonConvert.SerializeObject(errorObj, opts.Value.SerializerSettings) pour mieux la sérialisation de la cohérence à travers tous les points de terminaison.

    Approche 2

    Il y a un autre non-évident API appelée UseExceptionHandler qui fonctionne "ok" pour de simples scenarious:

    app.UseExceptionHandler(a => a.Run(async context =>
{
    var feature = context.Features.Get<IExceptionHandlerPathFeature>();
    var exception = feature.Error;

    var result = JsonConvert.SerializeObject(new { error = exception.Message });
    context.Response.ContentType = "application/json";
    await context.Response.WriteAsync(result);
}));

    Ce n'est pas très évident, mais de configurer facilement la gestion des exceptions. Cependant, je préfère encore le middleware approche plus de ce que je reçois plus de contrôle avec la possibilité d'injecter des dépendances nécessaires.

    • J'ai été me frappant la tête contre le bureau en essayant d'obtenir une mesure de middleware de travailler aujourd'hui, et il fonctionne essentiellement de la même façon (je l'utilise pour gérer l'unité de travail/de transaction pour une demande). Le problème que je me pose est qui ont soulevé des exceptions dans "suivant" ne sont pas pris dans le middleware. Comme vous pouvez l'imaginer, c'est problématique. Ce que je fais mal/manquant? Tous les pointeurs ou des suggestions?
    • la première pensée - assurez-vous que vous await tous vos appels asynchrones par exemple await context.SaveChangesAsync();. Il est difficile de deviner, sans voir le code. Je voudrais prendre un coup d'oeil si vous postez votre question avec plus de détails.
    • En général, je fais un mélange des deux, middleware et IExceptionFilter. Le filtre gère le contrôleur directement les erreurs, et j'utilise le middleware pour les plus "bas niveau" de la manipulation. Comme un soupçon, si quelqu'un a besoin d'exécuter du code par type d'exception dans le global gestionnaire, pour le rendre plus "lisible" n'hésitez pas à donner un coup d'oeil à une petite bibliothèque, je l'ai fait juste pour ça: medium.com/@nogravity00/...
    • Je vais avoir ce même problème. J'ai utilisé le code ci-dessus pour le middleware et enregistré. Puis je fais un appel api juste jette notimplemented. Je peux briser sur await next(context); mais la pause sur await HandleExceptionAsync(context, ex);. L'inspection du contexte, la réponse a un de 200 code. Je suis un peu perdu quant à pourquoi que l'exception a été levée, mais pas attrapé? Ne devrait-ce pas l'erreur d'être coincés ici?
    • J'ai compris quel était le problème. Je viens de l'enregistrement du middleware dans le mauvais endroit au Démarrage.cs de la classe. J'ai déménagé app.UseMiddleware<ErrorHandlingMiddleware>(); juste avant app.UseStaticFiles();. L'exception semble être pris correctement maintenant. Cela me mène à croire app.UseDeveloperExceptionPage(); app.UseDatabaseErrorPage(); app.UseBrowserLink(); Faire à l'interne de la magie middleware hackery pour obtenir le middleware de la commande de droite.
    • Cela semble comme il est seulement bon pour répondre à "attraper" des exceptions. Comment pouvez-vous avoir une API appel à une mauvaise URL de retourner une réponse JSON avec un code 404 plutôt que d'essayer de rediriger vers une page d'erreur personnalisée?
    • 404 est un peu différent car il ne soulève pas une exception, mais vous pouvez toujours vérifier context.Response.StatusCode == 404 dans la gestion des exceptions middleware et de réagir en tant que de besoin. Autres que ce cas, tous les les exceptions d'application sera pris dans le middleware. Espérons que cela aide.
    • context.Response.StatusCode à la ligne await next(context) est de 200 sur une mauvaise URL, pas de 404.
    • vous devriez vérifier après await next(context); comme MVC, à exécuter la première et de la condition définie par vous.
    • C'est toujours 200 après cette ligne.
    • Je suis d'accord que la coutume middleware peut être très utile, mais remettrait en question l'utilisation d'exceptions pour NotFound, non autorisée et BadRequest situations. Pourquoi ne pas simplement mettre le code d'état (à l'aide de NotFound (), etc.) et puis le gérer dans votre personnalisé middleware ou via UseStatusCodePagesWithReExecute? Voir devtrends.co.royaume-uni/blog/traitement des erreurs-en-asp.net-de base-web-api pour plus d'info
    • Quand vous dites "de retour vers le haut de la pile", il sonne comme si votre graphe de dépendance est plutôt complexe, mais dans une application typique, à l'aide de l'out-of-the-box fonctionnalité est plus simple et plus rapide. Sur un haut trafic du site, vous ne voulez pas de jeter des milliers de inutiles exceptions. Oui NotFound() est un contrôleur seule helper mais le sous-jacent NotFoundObjectResult peut être utilisé à partir de n'importe où. [Produit] et [SwaggerResponse] sont les méthodes recommandées pour indiquer les types de retour pour Swagger.
    • si votre entreprise est la logique dans les contrôleurs (ce qui est laid), sûr, vous pouvez utiliser NotFound, BadRequest etc. Mais pour les projets de production, même avec de simples n-tier de conception avec seulement 3 couches - contrôleurs, des services et des dépôts sera un énorme douleur. Dans certains de/la plupart des cas, vous pouvez obtenir loin de lui en retournant null à partir de la couche de service. Si null est une mauvaise pratique. Il n'y aurait nulle-vérifie partout. À l'aide d'exceptions est OK. Pas de null-chèques. Chute des performances n'est pas significatif et pour être honnête, je ferais le sacrifice de cette performance pour le code, d'une clarté toute la journée.
    • Hmm OK. Si cela fonctionne pour vous. Personnellement, je trouve le code qui pose excepions pour tous les événements de la journée, au fond de l'objet graphique beaucoup moins claire. Dans une application classique, je dirais que le premier niveau de viewmodel de validation et de non-autorisée de contrôles peuvent être traitées par des filtres d'actions ou de middleware sans l'aide d'exceptions. Pour les 404, le service retourne un objet avec un état de résultat et l'action permet de vérifier et de retour NotFound(). Pour les entreprises au niveau de la validation, il est plus discutable. Vous pouvez prendre la même approche qu'avec une erreur 404 ou l'utilisation d'exceptions.
    • Je pense qu'il est bon de répéter que, en réponse à votre question de départ où vous avez demandé à propos de la façon de capturer toutes les exceptions de l'application, ainsi que les exceptions de l'action des filtres, de la façon la plus simple pour ce faire est d'utiliser la fonctionnalité intégrée plutôt que de rouler votre propre - UseStatusCodePagesWithReExecute.
    • il bon pour la gestion des exceptions, mais comment puis-je Utiliser rediriger l'utilisateur vers ma propre page d'exception au lieu de résultat json?
    • ce n'est pas typique pour les api web pour une redirection à l'exception de la page de web de l'api exceptions doivent être manipulés par l'application cliente et le format JSON est préférable dans ce cas. Je n'ai pas essayé, mais vous pouvez vérifier Ashley Lee réponse ci-dessous.
    • mon exception ne sont pas pris dans le milieu de la vaisselle de la classe. J'utilise cette ligne pour lancer une exception " throw new Exception("erreur");" et il n'est pas pris. Pouvez-vous des conseils?
    • S'il vous plaît créer un stackoverflow question avec votre middleware et de démarrage de code de classe et de m'envoyer un lien, je vais jeter un oeil
    • Je vous remercie de la réponse, mais le code que j'utilise je l'ai pris de votre réponse. C'est donc le même et je ne veux pas dupliquer les ressources ici. Est-ce ok si je vous ai envoyé un lien pastebin?
    • le truc, c'est que l'erreur est renvoyée à postier en Json après votre solution. Le problème que j'ai fais allusion, c'est que l'exception est soulevée dans visual studio. J'ai imaginé que le moyen-ware est une mondial essayer de cache et doit attraper l'exception sans déclencher une alerte sur visual studio. Si c'est un comportement normal alors je pense que je suis bon.
    • vous êtes en debug et votre VS est configuré pour attraper certains types de "levée" des exceptions, vous verrez l'exception de VS. Ensuite, vous pouvez cliquer sur la touche F5 pour poursuivre l'exécution.
    • J'utilise un très similaire de m'approcher. Je voudrais juste ajouter que ce middleware va sérialiser en json par défaut Uppercase les noms de propriété, tout en MVC faire avec lowercase. C'est facilement réparable par le simple ajout d'un JsonSerializerSettings avec un CamelCasePropertyNamesContractResolver à la JsonConvert.SerializeObject(obj, settings) appel.
    • Bonjour @Andrei, pouvez vous s'il vous plaît m'aider avec dessous de la question stackoverflow.com/questions/52049727/...
    • C'est mauvais parce que c'est toujours la sérialisation JSON, en ignorant complètement la négociation de contenu.
    • Donc, même si vous avez quelques autres type de contenu que vous attendez du serveur de retour, il sera de retour JSON de toute façon....
    • point valide. C'est pourquoi j'ai dit que cet exemple est l'endroit où vous pouvez obtenir commencé, et non pas du résultat final. Pour 99% des Api JSON est plus que suffisant. Si vous vous sentez comme cette réponse n'est pas assez bon, n'hésitez pas à contribuer.
    • Bien que cet exemple fonctionne bien.. mais si je peux passer le Httpstatuscode d'origine comme de contrôleur ou toute la classe?
    • mettre en œuvre votre type d'exception avec HttpStatus. Il sera pris dans le middleware et sera en mesure d'utiliser ce statut.
    • un exemple ? voulez-vous dire quelque chose comme ceci blogs.msdn.microsoft.com/brandonh/2017/07/31/...
    • oui, similaires à ce. Vous pouvez utiliser mes de mise en œuvre et présenter votre HttpStatusCodeException(HttpStatusCode) et si le type d'exception que vous avez pris dans le middleware est HttpStatusCodeException - changer le code d'état de ce qui est à l'intérieur de cette exception. Vous avez l'idée 🙂
    • Merci copain pour me guider dans la bonne direction.. je suis venu avec une solution de fusionner les deux, et sera en poste en tant que réponse ci-dessous.. j'espère que ça aidera d'autres aussi..
    • Qui est soignée. propre réponse et le droit de codes
    • Il vaut la peine de mentionner que d'un comportement a changé depuis ASP.NET de Base 2.1 et de la [ApiController] attribut, plus précisément le modèle d'erreurs de validation (Bad Request). Pour plus d'info: stackoverflow.com/a/51159755/189429
    • Il est intégré dans le middleware que nous pouvons utiliser pour écrire un peu moins de code (il sera à peu près équivalent à cette réponse): stackoverflow.com/a/55166404/1671558
    • Merci :). J'ai utilisé IApplicationBuilder.UseExceptionHandler méthode et ça ne fonctionne pas pour moi, parce que j'ai appelé cette méthode après IApplicationBuildier.UseMvc(). Je l'ai changé comme vous l'avez suggéré et il a commencé à travailler.
    • Toute idée qui est la meilleure? Ou si vous utilisez à la fois? Sera l'un remplace l'autre?
    • approche 1 est mieux imo.

    InformationsquelleAutor Andrei
  2. 25

    Votre meilleur pari est d'utiliser un Middleware pour atteindre la journalisation vous êtes à la recherche pour. Vous voulez mettre votre enregistrement d'exception dans un middleware et de gérer vos pages d'erreur affiché à l'utilisateur dans un autre middleware. Qui permet la séparation de la logique et suit le design de Microsoft a présenté, avec les 2 middleware entraînement. Voici un bon lien pour la documentation de Microsoft: La gestion des erreurs dans ASP.Net de Base

    Pour votre exemple, vous souhaiterez peut-être utiliser une des extensions dans le StatusCodePage middleware ou rouler vos propres cette.

    Vous pouvez trouver un exemple ici pour l'enregistrement des exceptions: ExceptionHandlerMiddleware.cs

    public void Configure(IApplicationBuilder app)
{
    //app.UseErrorPage(ErrorPageOptions.ShowAll);
    //app.UseStatusCodePages();
    //app.UseStatusCodePages(context => context.HttpContext.Response.SendAsync("Handler, status code: " + context.HttpContext.Response.StatusCode, "text/plain"));
    //app.UseStatusCodePages("text/plain", "Response, status code: {0}");
    //app.UseStatusCodePagesWithRedirects("~/errors/{0}");
    //app.UseStatusCodePagesWithRedirects("/base/errors/{0}");
    //app.UseStatusCodePages(builder => builder.UseWelcomePage());
    app.UseStatusCodePagesWithReExecute("/Errors/{0}");  //I use this version

    //Exception handling logging below
    app.UseExceptionHandler();
}

    Si vous n'aimez pas que la mise en œuvre spécifique, alors vous pouvez aussi utiliser ELM Middleware, et voici quelques exemples: Elm Exception Middleware

    public void Configure(IApplicationBuilder app)
{
    app.UseStatusCodePagesWithReExecute("/Errors/{0}");
    //Exception handling logging below
    app.UseElmCapture();
    app.UseElmPage();
}

    Si cela ne fonctionne pas pour vos besoins, vous pouvez toujours passer votre propre Middleware composant en regardant leurs implémentations de la ExceptionHandlerMiddleware et la ElmMiddleware de saisir les concepts pour la construction de votre propre.

    Il est important d'ajouter la gestion d'exception middleware en dessous de la StatusCodePages middleware, mais au-dessus de tous les autres composants intergiciels. De cette façon, votre Exception middleware capture de l'exception, de l'enregistrer, puis de permettre à la demande de procéder à la StatusCodePage middleware qui permet d'afficher le message d'erreur de la page à l'utilisateur.

    • Vous êtes les bienvenus. J'ai également fourni un lien vers un exemple pour remplacer la valeur par défaut UseStatusPages sur le bord des cas qui peuvent mieux répondre à votre demande.
    • Notez que l'Orme ne persistent les journaux, et il est recommandé d'utiliser Serilog ou NLog de fournir à la sérialisation. Voir ELM journaux disparaît. Peut-on persister dans un fichier ou une base de données?
    • Le lien est rompu.
    InformationsquelleAutor Ashley Lee
  3. 21

    Dernière Asp.Net Core (à moins de 2.2, probablement plus tôt) est doté d'un middleware qui la rend un peu plus facile par rapport à la mise en œuvre dans l'acceptation réponse:

    app.UseExceptionHandler(a => a.Run(async context =>
{
    var exceptionHandlerPathFeature = context.Features.Get<IExceptionHandlerPathFeature>();
    var exception = exceptionHandlerPathFeature.Error;

    var result = JsonConvert.SerializeObject(new { error = exception.Message });
    context.Response.ContentType = "application/json";
    await context.Response.WriteAsync(result);
}));

    Il doit faire à peu près la même chose, juste un peu moins de code à écrire. N'oubliez pas de l'ajouter avant de UseMvc que l'ordre est important.

    InformationsquelleAutor Ilya Chernomordik
  4. 16

    Pour Configurer le comportement de gestion des exceptions par type d'exception, vous pouvez utiliser un Middleware de packages NuGet:

    Exemple de Code:

    public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddExceptionHandlingPolicies(options =>
{
options.For<InitializationException>().Rethrow();
options.For<SomeTransientException>().Retry(ro => ro.MaxRetryCount = 2).NextPolicy();
options.For<SomeBadRequestException>()
.Response(e => 400)
.Headers((h, e) => h["X-MyCustomHeader"] = e.Message)
.WithBody((req,sw, exception) =>
{
byte[] array = Encoding.UTF8.GetBytes(exception.ToString());
return sw.WriteAsync(array, 0, array.Length);
})
.NextPolicy();
//Ensure that all exception types are handled by adding handler for generic exception at the end.
options.For<Exception>()
.Log(lo =>
{
lo.EventIdFactory = (c, e) => new EventId(123, "UnhandlerException");
lo.Category = (context, exception) => "MyCategory";
})
.Response(null, ResponseAlreadyStartedBehaviour.GoToNextHandler)
.ClearCacheHeaders()
.WithObjectResult((r, e) => new { msg = e.Message, path = r.Path })
.Handled();
});
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseExceptionHandlingPolicies();
app.UseMvc();
}
    InformationsquelleAutor Ihar Yakimush
  5. 15

    Bien accepté réponse m'a beaucoup aidé, mais je voulais passer HttpStatusCode dans mon middleware pour gérer le code d'état d'erreur lors de l'exécution.

    Selon ce lien j'ai eu une idée de faire de même. J'ai donc fusionné les Andreï Répondre avec ce. Donc mon code final est ci-dessous:

    1. Classe de Base

    public class ErrorDetails
{
public int StatusCode { get; set; }
public string Message { get; set; }
public override string ToString()
{
return JsonConvert.SerializeObject(this);
}
}

    2. Classe D'Exception Personnalisée De Type

     public class HttpStatusCodeException : Exception
{
public HttpStatusCode StatusCode { get; set; }
public string ContentType { get; set; } = @"text/plain";
public HttpStatusCodeException(HttpStatusCode statusCode)
{
this.StatusCode = statusCode;
}
public HttpStatusCodeException(HttpStatusCode statusCode, string message) : base(message)
{
this.StatusCode = statusCode;
}
public HttpStatusCodeException(HttpStatusCode statusCode, Exception inner) : this(statusCode, inner.ToString()) { }
public HttpStatusCodeException(HttpStatusCode statusCode, JObject errorObject) : this(statusCode, errorObject.ToString())
{
this.ContentType = @"application/json";
}
}

    3. Exception Personnalisée Middleware

    public class CustomExceptionMiddleware
{
private readonly RequestDelegate next;
public CustomExceptionMiddleware(RequestDelegate next)
{
this.next = next;
}
public async Task Invoke(HttpContext context /* other dependencies */)
{
try
{
await next(context);
}
catch (HttpStatusCodeException ex)
{
await HandleExceptionAsync(context, ex);
}
catch (Exception exceptionObj)
{
await HandleExceptionAsync(context, exceptionObj);
}
}
private Task HandleExceptionAsync(HttpContext context, HttpStatusCodeException exception)
{
string result = null;
context.Response.ContentType = "application/json";
if (exception is HttpStatusCodeException)
{
result = new ErrorDetails() { Message = exception.Message, StatusCode = (int)exception.StatusCode }.ToString();
context.Response.StatusCode = (int)exception.StatusCode;
}
else
{
result = new ErrorDetails() { Message = "Runtime Error", StatusCode = (int)HttpStatusCode.BadRequest }.ToString();
context.Response.StatusCode = (int)HttpStatusCode.BadRequest;
}
return context.Response.WriteAsync(result);
}
private Task HandleExceptionAsync(HttpContext context, Exception exception)
{
string result = new ErrorDetails() { Message = exception.Message, StatusCode = (int)HttpStatusCode.InternalServerError }.ToString();
context.Response.StatusCode = (int)HttpStatusCode.BadRequest;
return context.Response.WriteAsync(result);
}
}

    4. Méthode D'Extension

    public static void ConfigureCustomExceptionMiddleware(this IApplicationBuilder app)
{
app.UseMiddleware<CustomExceptionMiddleware>();
}

    5. Configurer la Méthode de démarrage.cs

    app.ConfigureCustomExceptionMiddleware();
app.UseMvc();

    Maintenant ma méthode d'ouverture de session dans le Compte du contrôleur :

     try
{
IRepository<UserMaster> obj = new Repository<UserMaster>(_objHeaderCapture, Constants.Tables.UserMaster);
var Result = obj.Get().AsQueryable().Where(sb => sb.EmailId.ToLower() == objData.UserName.ToLower() && sb.Password == objData.Password.ToEncrypt() && sb.Status == (int)StatusType.Active).FirstOrDefault();
if (Result != null)//User Found
return Result;
else//Not Found
throw new HttpStatusCodeException(HttpStatusCode.NotFound, "Please check username or password");
}
catch (Exception ex)
{
throw ex;
}

    Ci-dessus, vous pouvez voir si je n'ai pas trouvé l'utilisateur puis en soulevant le HttpStatusCodeException dans lequel j'ai passé HttpStatusCode.NotFound état et un message personnalisé
    middleware

    catch (HttpStatusCodeException ex)

    bloqué sera appelé, ce qui fera passer le contrôle

    privé Tâche HandleExceptionAsync(HttpContext contexte,
    HttpStatusCodeException exception) méthode

    .

    Mais que faire si j'ai eu d'erreur à l'exécution avant? Pour ce que j'ai utilisé essayez bloc catch qui jeter l'exception et sera piégé dans catch (Exception exceptionObj) de bloc et fera passer le contrôle

    Tâche HandleExceptionAsync(HttpContext contexte, Exception exception)

    méthode.

    J'ai utilisé un seul ErrorDetails classe pour l'uniformité.

    • Les réponses devraient être comme ça.
    • Grande Réponse. Apprécier le partage des connaissances
    • Où mettre de la méthode d'extension? Malheureusement, dans la startup.cs dans void Configure(IapplicationBuilder app) j'obtiens une erreur IApplicationBuilder does not contain a definition for ConfigureCustomExceptionMiddleware. Et j'ai ajouté la référence, où CustomExceptionMiddleware.cs est.
    InformationsquelleAutor Arjun
  6. 13

    Tout d'abord, merci à Andrei comme je l'ai basé ma solution sur son exemple.

    Je suis, y compris le mien, car c'est un exemple plus complet et peut enregistrer des lecteurs d'un certain temps.

    La limitation de Andrei a une approche qui ne gèrent l'abattage, la capture potentiellement utile variables de requête et de la négociation de contenu (il sera toujours le retour JSON n'importe ce que le client a demandé - XML /texte etc).

    Mon approche est d'utiliser un ObjectResult qui nous permet d'utiliser la fonctionnalité de boulangerie en MVC.

    Ce code empêche également la mise en cache de la réponse.

    La réponse d'erreur a été décoré de telle manière qu'il peut être sérialisé en XML sérialiseur. 

    public class ExceptionHandlerMiddleware
{
private readonly RequestDelegate next;
private readonly IActionResultExecutor<ObjectResult> executor;
private readonly ILogger logger;
private static readonly ActionDescriptor EmptyActionDescriptor = new ActionDescriptor();
public ExceptionHandlerMiddleware(RequestDelegate next, IActionResultExecutor<ObjectResult> executor, ILoggerFactory loggerFactory)
{
this.next = next;
this.executor = executor;
logger = loggerFactory.CreateLogger<ExceptionHandlerMiddleware>();
}
public async Task Invoke(HttpContext context)
{
try
{
await next(context);
}
catch (Exception ex)
{
logger.LogError(ex, $"An unhandled exception has occurred while executing the request. Url: {context.Request.GetDisplayUrl()}. Request Data: " + GetRequestData(context));
if (context.Response.HasStarted)
{
throw;
}
var routeData = context.GetRouteData() ?? new RouteData();
ClearCacheHeaders(context.Response);
var actionContext = new ActionContext(context, routeData, EmptyActionDescriptor);
var result = new ObjectResult(new ErrorResponse("Error processing request. Server error."))
{
StatusCode = (int) HttpStatusCode.InternalServerError,
};
await executor.ExecuteAsync(actionContext, result);
}
}
private static string GetRequestData(HttpContext context)
{
var sb = new StringBuilder();
if (context.Request.HasFormContentType && context.Request.Form.Any())
{
sb.Append("Form variables:");
foreach (var x in context.Request.Form)
{
sb.AppendFormat("Key={0}, Value={1}<br/>", x.Key, x.Value);
}
}
sb.AppendLine("Method: " + context.Request.Method);
return sb.ToString();
}
private static void ClearCacheHeaders(HttpResponse response)
{
response.Headers[HeaderNames.CacheControl] = "no-cache";
response.Headers[HeaderNames.Pragma] = "no-cache";
response.Headers[HeaderNames.Expires] = "-1";
response.Headers.Remove(HeaderNames.ETag);
}
[DataContract(Name= "ErrorResponse")]
public class ErrorResponse
{
[DataMember(Name = "Message")]
public string Message { get; set; }
public ErrorResponse(string message)
{
Message = message;
}
}
}
    • 100% d'accord, pas de négociation de contenu est limité et n'est pas entièrement approche de travail
    InformationsquelleAutor CountZero
  7. 7

    Tout d'abord, configurez ASP.NET Core 2 Startup pour ré-exécuter vers une page d'erreur pour les erreurs de du serveur web et les exceptions non gérées.

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment()) {
//Debug config here...
} else {
app.UseStatusCodePagesWithReExecute("/Error");
app.UseExceptionHandler("/Error");
}
//More config...
}

    Ensuite, définir un type d'exception qui vous permettra de générer des erreurs avec les codes d'état HTTP.

    public class HttpException : Exception
{
public HttpException(HttpStatusCode statusCode) { StatusCode = statusCode; }
public HttpStatusCode StatusCode { get; private set; }
}

    Enfin, dans votre contrôleur pour la page d'erreur, personnaliser la réponse basée sur la raison de l'erreur, et si la réponse va être perçu directement par un utilisateur final. Ce code suppose que toutes les API Url commencer avec /api/.

    [AllowAnonymous]
public IActionResult Error()
{
//Gets the status code from the exception or web server.
var statusCode = HttpContext.Features.Get<IExceptionHandlerFeature>()?.Error is HttpException httpEx ?
httpEx.StatusCode : (HttpStatusCode)Response.StatusCode;
//For API errors, responds with just the status code (no page).
if (HttpContext.Features.Get<IHttpRequestFeature>().RawTarget.StartsWith("/api/", StringComparison.Ordinal))
return StatusCode((int)statusCode);
//Creates a view model for a user-friendly error page.
string text = null;
switch (statusCode) {
case HttpStatusCode.NotFound: text = "Page not found."; break;
//Add more as desired.
}
return View("Error", new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier, ErrorText = text });
}

    ASP.NET Core journal les détails de l'erreur pour le débogage, donc un code de statut peut être tout ce que vous voulez offrir à un (potentiellement non fiables) demandeur. Si vous voulez montrer plus d'infos, vous pouvez améliorer HttpException à fournir. Pour les erreurs de l'API, vous pouvez mettre JSON codé erreur d'infos dans le corps du message en remplaçant return StatusCode... avec return Json....

    InformationsquelleAutor Edward Brey