Подтвердить что ты не робот

Эквивалент HttpResponseException/IHttpActionResponse для.net Core webapi 2 (не mvc)

Когда я читаю о webapi для ответа на запросы и обработки ошибок, все основывается на:

IHttpActionResult
HttpResponseException

Но когда вы создаете проект web-проекта.net, они недоступны. Я могу найти IActionResult, который кажется эквивалентным?

Но я собираюсь объездить круги, пытаясь найти действительно очень простую вещь, которая заключается в том, как обрабатывать ошибки в.net-ключевой веб-странице, поскольку исключение HttpResponseException недоступно. У меня создается впечатление, что все с "http" в нем, просто для полного приложения MVC.

Все, что я хочу сделать, это вернуть ошибку, конечно, это должно быть просто...

Ответ 1

IActionResult является эквивалентом IHttpActionResult, как вы предложили. Это часть консолидации того, что было известно как MVC и Web API в ASP.NET Core MVC.

Что касается HttpResponseException, то это полностью удалено в ASP.NET Core. В GitHub есть интересная проблема, где Дэвид Фоулер дает объяснение, почему это так:

Просто классика, "мы не хотим, чтобы люди, использующие исключения для контроля потока" парадигмы. Люди делали такие вещи, как использовать его из своей бизнес-логики, что все-таки не так. Я не могу говорить о проблемах с производительностью, потому что я не измерил, но исключение, предназначенное для того, чтобы быть пойманным, чтобы получить некоторые данные, хуже, чем просто вернуть этот результат.

Предлагаемая альтернатива этому - использовать различные реализации IActionResult для создания ответов JSON, возврата ошибок и т.д. Опять же, из проблемы:

Мое предложение состояло в том, чтобы вернуть метод действия IActionResult (или изменение асинхронности).

Причина, по которой поддерживаются как IActionResult, так и объект, заключается в том, что каждый из них соответствует различным целям и различным стилям. Для некоторых из простейших случаев приятно использовать объект, но он не является мощным вообще. Для полного контроля есть IActionResult, который следует за хорошо известным "командным шаблоном".

Шаблон IActionResult позволяет контроллеру явно указывать, что должно произойти в результате действия: какой-то код ошибки, перенаправление, сериализованный объект данных, визуализированное представление и т.д.

Если вы хотите обрабатывать ошибки вне контроллеров, вам может быть полезно ознакомиться с документами по этому вопросу, в которых перечислены детали использования промежуточного программного обеспечения или фильтров для обработки ошибок. В комментариях есть ссылка на учебник, в котором более подробно описаны некоторые аспекты обработки ошибок.

Для полноты здесь приведен код из учебника для подхода промежуточного программного обеспечения:

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);
      }
    });
 }
);

Есть также более подробная информация о подходе IExceptionFilter, но я не буду принимать этот ответ больше, чем он есть.