Когда IExceptionHandlerPathFeature может иметь значение null с ExceptionHandlerMiddleware в Asp.Net Core
Microsoft предоставляет этот пример для ExceptionHandlerMiddlewareздесь. Это отрывок:
app.UseExceptionHandler(errorApp =>
{
errorApp.Run(async context =>
{
...
var exceptionHandlerPathFeature = context.Features.Get<IExceptionHandlerPathFeature>();
if (exceptionHandlerPathFeature?.Error is FileNotFoundException)
{
await context.Response.WriteAsync("File error thrown!");
}
...
});
});
Я не совсем понимаю, зачем им использовать оператор ?. для получения исключения? Можно ли запустить этот делегат без IExceptionHandlerPathFeature? Не кажется логичным иметь обработчик исключений без гарантированного доступа к исключению.
Здесь — это код, и не представляется возможным иметь там нуль.
Теоретически это возможно, но это просто POCO в упражняться
Это не ошибка, которая может быть нулевой, а exceptionHandlerPathFeature, если она не найдена в коллекции context.Features
да, и это может быть null как я вижу, но я точно не знаю случаев на данный момент.
В обычных сценариях он никогда не будет нулевым. Тем не менее, вы можете реализовать IWebHostочень упрощенно, и это будет. Реализация по умолчанию будет иметь эту функцию, но это не значит, что все реализации будут. Кроме того, рекомендуется всегда кодировать вокруг нулей. Возможно, он никогда не будет нулевым, но для нулевого значения существует потенциал, так что этот случай покрывается. Возможно, это особенно важно для обработчика исключений, поскольку вы можете попасть в бесконечный цикл из-за того, что обработчик сам генерирует исключения.
Да, я немного не так написал вопрос, я вижу :) Исправлю. Теперь зачем нам обработчик исключений, который не гарантирует способ получить доступ к исключению? Разве это не странно?
@ChrisPratt Не могу полностью согласиться с тем, что всегда рекомендуется кодировать против нуля, поскольку, на мой взгляд, это защитное программирование, и я бы предпочел увидеть исключение, чем получить совершенно неожиданный нуль. К счастью, в следующем C# будет немного лучше, когда null не будет разрешен, хотя это другое обсуждение в другой день :)
На самом деле строгая проверка нулевого значения в C# 8.0 не является обязательной. Это защитное кодирование, но в этом и смысл. Я не уверен, что вы подразумеваете под «неожиданными нулями», потому что, когда вы добавляете нулевую охрану, в этот момент никакой нуль не является «неожиданным». Исключения — это, безусловно, стратегия худший, тем более что NullReferenceExceptions — это исключительно исключения во время выполнения. В общем, полагаться на исключения плохо, и следует полностью избегать исключений во время выполнения.
у меня ExceptionDetails имеет значение null в следующем коде: var ExceptionDetails = HttpContext.Features.Get<IExceptionHandlerPathFeature>();
Ответы 1
В моей конкретной ситуации у меня был собственный контроллер ошибок с одним из действий:
[Route("Error")]
public IActionResult Error(ErrorViewModel model)
{
var exceptionDetails = HttpContext.Features.Get<IExceptionHandlerPathFeature>();
model.Code = 500;
_logger.Error($"The path {exceptionDetails?.Path} threw an exception " +
$"{exceptionDetails?.Error}");
return View(nameof(Error), model);
}
IExceptionHandlerPathFeature был нулевым всякий раз, когда пользователь вручную вводит маршрут моей страницы с ошибкой в браузере. Поэтому мне пришлось поставить нулевой условный оператор, чтобы ограничить исключение нулевой ссылки.
если
IExceptionHandlerPathFeatureреализация не может быть найдена для чтения, то это может бытьnull