Как правильно обрабатывать ошибки AJAX в ASP. NET Core MVC? - PullRequest
1 голос
/ 10 июля 2020

Фон:

Я настраиваю обработку ошибок в приложении ASP. NET Core 2.2 MVC. В среде разработки я использую app.UseDeveloperExceptionPage();, а в производстве - app.UseExceptionHandler("/Error/Index");. Я перехожу на правильную страницу ошибки во время запросов, отличных от AJAX (отправка обычной формы), в зависимости от среды.

Если на сервере возникает исключение во время запроса AJAX, я хочу, чтобы приложение отображать правильную страницу ошибки в зависимости от среды.

Я уже настроил все, что описано выше, как вы можете видеть в моих примерах кода ниже.

Проблема / проблема :

Хотя это работает (хотя все еще необходимо выполнить TODO в функции InitializeGlobalAjaxEventHandlers), у меня есть некоторые проблемы.

С не- AJAX вызовами в MVC , похоже, что существует «официальный / правильный» способ сделать это с помощью app.UseDeveloperExceptionPage(); и app.UseExceptionHandler("/Error/Index");, который автоматически перенаправляет программу на страницу с ошибкой. Однако с окончанием обработки ошибок AJAX я не чувствую такой уверенности, потому что я собрал ее вместе с частями из различных решений, которые я исследовал. Я волнуюсь, я не знаю, что могло go неправильно.

Вопрос:

Это правильный способ обработки ошибок во время AJAX запросов в MVC? Может, что-то go не так с этой настройкой? Это каким-то образом неправильно или слишком далеко от общепринятых стандартов?

Код:

Startup.cs> Метод настройки:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    //using build config to use the correct error page: https://stackoverflow.com/a/62177235/12300287
    //Reason why we don't use environmental variables is because we can't guarantee access to clients' 
    //machines to create them.
#if (DEVELOPMENT || STAGING)
    app.UseDeveloperExceptionPage();
#else
    app.UseExceptionHandler("/Error/Index");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
#endif

    app.UseHttpsRedirection();
    app.UseStaticFiles();
    //app.UseCookiePolicy();

    app.UseAuthentication();

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=UserAccess}/{action=Index}/{id?}");
    });
}

ErrorController .cs: ​​

public class ErrorController : Controller
{
    [AllowAnonymous]
    public IActionResult Index()
    {
        IExceptionHandlerPathFeature exceptionDetails = HttpContext.Features.Get<IExceptionHandlerPathFeature>();
        Exception exception = exceptionDetails?.Error; // Here will be the exception details.

        Error model = new Error();
        model.ID = exception.HResult;
        model.Message = exception.Message;
        model.Path = exceptionDetails.Path;

        return View(model);
    }
}

Global AJAX обработчик события ошибки (оператор if предназначен для обработки аутентификации):

function InitializeGlobalAjaxEventHandlers() {
    $(document).ajaxError(function (event, xhr, ajaxSettings, thrownError) {
        //status is set in the [AuthorizeAjax] action filter if user isn't authenticated
        if (xhr.status == 403) {
            var response = $.parseJSON(xhr.responseText);
            window.location = response.redirectUrl;
        }

        //the document HTML is replaces by responseText value, which contains the HTML of error page
        document.write(xhr.responseText);

        //TODO: will need to display an error page if responseText is empty, which
        //can happen if an AJAX request doesn't reach the server (for example: if URL is incorrect).
    });
}

Ответы [ 2 ]

0 голосов
/ 14 июля 2020

Как вы объяснили, необходимо рассмотреть два потока кода. Один находится на клиенте, а другой на сервере.

Хотя сервер может возвращать коды и сообщения для неожиданных результатов, клиент все же должен быть надежным и автономным. Например, если сервер недоступен, на клиенте может возникнуть ошибка тайм-аута, которую он должен обработать. Как упоминалось выше, вы можете обнаруживать ошибки на локальном и глобальном уровне Ajax.

Сервер также может генерировать ответ об ошибке, который никогда не достигает клиента.

В некоторых проектах, которые я выполнял следующее: - Если на сервере сгенерирован неожиданный результат, он регистрируется в базе данных и возвращает сообщение JSON как ошибку.

Если на клиенте генерируется неожиданный результат , вызывается служба сервера для регистрации ошибки в базе данных.

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

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

0 голосов
/ 14 июля 2020

Это правильный способ обработки ошибок при запросах AJAX в MVC? Может что-то go не так с этой настройкой? Является ли это каким-либо образом неправильным или слишком далеким от общепринятых стандартов?

Насколько мне известно, не существует единого / официального способа обработки Ajax ошибок в ASP. NET Core MVC project.

Обычно мы показываем конкретное c сообщение / содержимое подтверждения с помощью Ajax функции обратного вызова при ошибке, если запрос Ajax завершается неудачно, вместо того, чтобы напрямую отображать подробную информацию об исключении пользователю клиента, что могло бы помочь

Если вы указали требование c, которое требует отображения страницы исключений разработчика / настраиваемой страницы ошибок, в то время как запрос Ajax завершается неудачно, как и вы, вы можете динамически записать возвращенное responseText в документ HTML, используя document.write(xhr.responseText); в глобальном обработчике ошибок.

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