«Необработанное» исключение в ASP. NET Core 3.1 - PullRequest
0 голосов
/ 09 апреля 2020

Я получил исключение в моем файле журнала. Дело в том, что в моем методе Startup.Configure () есть глобальный обработчик исключений:

app.UseExceptionHandler("/Home/Error");

, и он действительно вызывается. Таким образом, исключение обрабатывается. Как убрать это сообщение из файла журнала?

Спасибо!

ERROR|Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware|An unhandled exception has occurred while executing the request. Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Request body too large.
   at Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException.Throw(RequestRejectionReason reason)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1ContentLengthMessageBody.OnReadStarting()
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.MessageBody.TryStart()
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1ContentLengthMessageBody.ReadAsyncInternal(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream.ReadAsyncInternal(Memory`1 buffer, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.WebUtilities.BufferedReadStream.EnsureBufferedAsync(Int32 minCount, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.WebUtilities.MultipartReaderStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.WebUtilities.StreamHelperExtensions.DrainAsync(Stream stream, ArrayPool`1 bytePool, Nullable`1 limit, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.WebUtilities.MultipartReader.ReadNextSectionAsync(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Http.Features.FormFeature.InnerReadFormAsync(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Mvc.ModelBinding.FormValueProviderFactory.AddValueProviderAsync(ValueProviderFactoryContext context)
   at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.CreateAsync(ActionContext actionContext, IList`1 factories)
   at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.TryCreateAsync(ActionContext actionContext, IList`1 factories)
   at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Localization.RequestLocalizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)```

Ответы [ 2 ]

1 голос
/ 09 апреля 2020

Надежная регистрация исключений - это единственное, что может сделать глобальный обработчик исключений. После этого всегда следует включать исключение go. Для ведения журнала он должен охватывать широкий диапазон, что означает, что он будет перехватывать фатальные исключения, и они всегда должны иметь значение go. Глобальный обработчик - способ поздно что-либо исправить. Возможно, уже поздно будет что-то регистрировать должным образом, поскольку к тому времени большинство вещей уже выходит из области видимости.

Чтобы знать, как правильно с этим справляться, нам сначала нужно классифицировать это. Я использую эту систему классификации: https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/

BadHttpRequestException выглядит как исключение с головой. Те, которые вы никогда не должны игнорировать и в идеале никогда не ловить. Те, кого вы должны исправить .

Однако, поскольку мы имеем дело с сетью, есть вероятность, что это может быть Exogenous или Vexing Exception. Если это один из них, вы должны поймать его как можно ближе к тому месту, где он находится, и как можно точнее. Также дайте вызывающему коду подсказку, что что-то пошло не так, поэтому ожидаемого результата нет. Однажды я написал этот пример для реплицированного TryParse:

//Parse throws ArgumentNull, Format and Overflow Exceptions.
//And they only have Exception as base class in common, but identical handling code (output = 0 and return false).

bool TryParse(string input, out int output){
  try{
    output = int.Parse(input);
  }
  catch (Exception ex){
    if(ex is ArgumentNullException ||
      ex is FormatException ||
      ex is OverflowException){
      //these are the exceptions I am looking for. I will do my thing.
      output = 0;
      return false;
    }
    else{
      //Not the exceptions I expect. Best to just let them go on their way.
      throw;
    }
  }

  //I am pretty sure the Exception replaces the return value in exception case. 
  //So this one will only be returned without any Exceptions, expected or unexpected
  return true;
}

Vexing части Parse? Те попадают прямо туда и общаются через возвращение bool. Мне пришлось перехватывать или обрабатывать трижды код обработки, поэтому я приложил все усилия с is проверками для фильтрации позже.

Для общих приличных практик у меня есть одна статья . Вместе с приведенной выше классификацией это является основой всех моих решений по обработке исключений.

0 голосов
/ 09 апреля 2020

Я советую вам не отключать ошибки журналирования, потому что это один из основных способов обнаружения проблемы пользователей. В любом случае, если вы хотите отключить ведение журнала ошибок, вы можете сделать это из конфигурации. Файл конфигурации по умолчанию - "appsettings. json" file:

"Logging": {
  "LogLevel": {
    "Default": "Information",
    "Microsoft": 6,
    "Microsoft.Hosting.Lifetime": 6
  }
}

. Это подавит любое сообщение об ошибке от Microsoft или Hosting. Обратите внимание, что существует также файл «appsettings.Development. json», который используется в среде разработки, и вы можете также sh отключить ведение журнала там.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...