Комментарии 7
Правда "глобальную"? Правда-правда? Ошибки в IHostedService туда тоже попадут?
Дауж. Заголовок провокативный…
Я вот толком не нашел хорошего способа обработки исключений которые могут возникнуть в IHostedService или же в Startup. Ничего кроме как создания логгера и логирования всех исключений для их разбора позднее. Может есть более элегантный способ?
Я вот толком не нашел хорошего способа обработки исключений которые могут возникнуть в IHostedService или же в Startup. Ничего кроме как создания логгера и логирования всех исключений для их разбора позднее. Может есть более элегантный способ?
Ну если все сервисы унаследовать от одного базового в котором все в try/catch завернуть, то не так уж и не элегантно
Cо Startup (который класс, я правильно понял?) вообще проблем не вижу: там же идет чисто синхронное однопоточное выполнение кода, так что обработчик исключения можно повесить в любом месте вокруг вызова, через который идет обращение к методам класса Startup.
В частности, все обращение к Startup локализовано внутри делегата, который передается в метод расширения ConfigureWebHostDefaults для интерфейса IHost (в шаблоне приложения этот делегат сделан в виде лямбды webBuilder => {webBuilder.UseStartup<Startup>();}) В этот метод не обязательно передавать лямбду, можно передать любой Action<IWebHostBuilder>. Сделайте, к примеру, экземпляр своего класса с методом, в котором вызов UseStartup<> обернут в try/catch, передайте его в качестве делегата в ConfigureWebHostDefaults и обрабатывайте исключения, как пожелаете.
В частности, все обращение к Startup локализовано внутри делегата, который передается в метод расширения ConfigureWebHostDefaults для интерфейса IHost (в шаблоне приложения этот делегат сделан в виде лямбды webBuilder => {webBuilder.UseStartup<Startup>();}) В этот метод не обязательно передавать лямбду, можно передать любой Action<IWebHostBuilder>. Сделайте, к примеру, экземпляр своего класса с методом, в котором вызов UseStartup<> обернут в try/catch, передайте его в качестве делегата в ConfigureWebHostDefaults и обрабатывайте исключения, как пожелаете.
В частности, все обращение к Startup локализовано внутри делегата, который передается в метод расширения ConfigureWebHostDefaults для интерфейса IHost
Это точно не так, потому что обращения к Startup происходят в разные этапы жизни приложения.
Начнем с простого вопроса: вы про какую конкретно версию ASP.NET Core говорите?
Про 3.1
PS Я посмотрел внимательно, и, скорее всего, вы правы: этот класс (или вызов создающего его делегата) помещается в качестве реализации Singleton в контейнер сервисов, после чего может быть вызван где-то дальше.
PPS В частности, Configure вызывается там, где производится конфигуирование конвейера обработки запросов, в частности — в методе, который вызывается уже из Build(). Так что я был не прав. Поторопился.
PS Я посмотрел внимательно, и, скорее всего, вы правы: этот класс (или вызов создающего его делегата) помещается в качестве реализации Singleton в контейнер сервисов, после чего может быть вызван где-то дальше.
PPS В частности, Configure вызывается там, где производится конфигуирование конвейера обработки запросов, в частности — в методе, который вызывается уже из Build(). Так что я был не прав. Поторопился.
Для ASP.NET Core все достаточно просто и понятно, а вот как организовать глобальную обработку исключейний для Blazor server-side непонятно. Т.е. вообще непонятно. Все статьи включая официальную доку Microsoft говорят «сейчас все объясню» и начинают лепетать «вставьте try/catch» вообще везде. Но это-же не решение! Вопрос-то был как сделать глобальный перехват и (допустим) редирект. Понятно что SignalR накладывает ограничения, но нигде, вообще нигде, не написано, что типа все расходимся в SignalR так сделать нельзя потому, что дизайн. Особо бесят копии официальной страницы в частных блогах под другим названием.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализуем глобальную обработку исключений в ASP.NET Core приложении