Удобная навигация по видео :) 0:00 - Начало 1:19 - В чём состоит проблема? 3:22 - Решение: Global Exceptions Handling 5:22 - Live example 7:13 - Пример: Создаём проект в Visual Studio 2022 (.NET6)
Было бы круто еще: 1) Как работать с http, формирование запросов, куки, хедеры и т.д 2) Работа с кешем 3) Аутентификация и авторизация, роли 4) Горячие клавиши и фишки в IDE
Очень качественный контент, мне 29, работаю первый год, свитчер из околоинженерной темы. Нашла ваши видео категорически полезными. Благодарю и желаю удачи
А зачем в ErrorDto есть поле StatusCode которое по сути дублирует HttpStatuscode, который в свою очередь внешняя система и так может получить из ответа?
Внимательный зритель на вес золота 🙂 Конвертация в json не требуются, так как этим занимается метод WriteAsJsonAsync() в HttpResponse. В видео я сделал это излишне. В исходниках проекта на GitHub я убрал лишние конвертации. Спасибо за внимательность! 👍
Приветствую. Склонировал ваш репозиторий, появился вопрос. При отправке запроса IDE тормозит на исключении и только потом проходит по пайплайну и обрабатывает исключение. Подскажите как это исправить?
Спасибо за ролик! Хотелось бы увидеть видео сравнение всех способов обработки исключений, в том числе и для mvc проекта. Допустим я использую реализацию для IExceptionFilter интерфейса.
Здравствуйте! Спасибо за видео, подскажите как Вы относитесь к обработки ошибок через var contextFeature = context.Features.Get(); После проверяем его на null и если фича содержит информацию по ошибкам то можно добавить соответствующие статусы с использованием swith context.Response.StatusCode = contextFeature.Error switch { _ => StatusCodes.Status500InternalServerError }; Я его использую в своих проектах. Подскажите какой способ лучше? Спасибо!
Здравствуйте! Да, это еще один распространённый способ обработки исключений. Лично для меня, использование middleware проще. Возможно, существуют тонкие отличия в применении этих способов, но мне не приходилось сталкиваться с ними в решении реальных бизнес-задач. Если вам удобно пользоваться IExceptionHandlerFeature или в вашей команде так принято, то я не вижу в этом проблемы. Если вам удастся узнать о важных отличиях, буду рад если поделитесь информацией 😊
не ставил себе студию 2022, разрабы что, избавились от класса startup в шаблонах? И почему класс Program так странно выглядит, без объявления класса и код не в блоке, какие-то странные нововведения?
Хорошее видео) но как ловить эксепш если юзер не авторизован или например не имеет достаточно прав? Даже если в пайплайне встроить самым первым данный middleware ошибку он не перехватывает(
UPD: разобрался. Забыл что добавил кастомный AuthorizationHandler, и если в нем не выкидывать ошибку а просто фиксировать context.Fail(); то и try catch ничего не поймает
Ребятушки, пожалуйста НИКОГДА так не делайте как автор в этом видосе, НИКОГДА 1) не отключайте защиту от нуллреференсов (она заставляет вас учиться писать код правильно, понимать что вы пишите и защищает от 99% косяков, в которые вы без неё обязательно вляпаетесь) и 2) не обрабатывайте исключения не явным образом в миддлвэйре (вы так никонда не научитесь работать с ошибками, обработка исключений - НАМНОГО сложнее, чем просто логирование.. и для логирование исключений есть специальные инструменты и стандартные подходы, которые не имеют ничего общего с глобальной обработкой, вы легко можете потерять работу и получить волчий билет на всю жизнь, если не правильно обработаете всего одно, но очень важное, исключение.. а вы обязательно его не обработаете, если будете всегда ловить их глобально и не научитесь работать с ними правильно). Вы сами себя закопаете в яму говнокодерства в самом начале пути и выбраться из этой ямы потом будет очень очень сложно. Это самые вредные советы, какие только можно дать начинающим разработчикам. Я вообще сначала подумал, шо автор троллит просто, но нет, он серьёзно..
@@rar24 пример правильной обработки ошибок - это как минимум 1) определить точечно где и что может пойти не так и чем это грозит (в том числе проверить какие эксепшен могут кидать те методы, которыми вы пользуетесь и в каких ситуациях) 2) спланировать поведение системы в случае если что то пошло не так: откатить ранее сделанные изменения если возможно, заинфорсить политику ретрая (или вырубить серкут брейкер) если возможно 3) "упасть" как можно скорее (для чего и существует те самые эксепшены), что бы не допустить усугубления ситуации 4) сообщить в систему мониторинга о своём состоянии. Все это требует точечного подхода и понимания: как работает ваше приложение, что может пойти не так, что делать если что то пошло не так, в каких случаях ошибки можно игнорировать, а в каких нельзя. В случае каких то серьёзных ошибок у вас обязательно должны быть данные о том, что произошло и почему. Что бы можно было 1) постфактум исправить состояние, которое возникло по ошибке 2) проанализировать что пошло не так (Root cause analysis, RCA) и что сделать, что бы это не повторилось. Эксепшен нужно обязательно уметь отлавливать и вообще правильно с ними работать, это чрезвычайно полезный инструмент в любом рекавери и RCA.
Про нуллабле контекст я согласен с вами, его ни в коем случае не надо отключать, так ide будет вас заставлять писать проверки на null. А вот по поводу глобальной обработки исключений, вроде в аспнет 7 исключения в запросах не крашат приложение, а логгируются по дефолту. Или я ошибаюсь?
Да, вы правы. В комментариях ниже уже указывали на это. Повторюсь: Конвертация в json не требуются, так как этим занимается метод WriteAsJsonAsync() в HttpResponse. В видео я сделал это излишне. В исходниках проекта на GitHub я убрал лишние конвертации. Спасибо за внимательность! 👍
Удобная навигация по видео :)
0:00 - Начало
1:19 - В чём состоит проблема?
3:22 - Решение: Global Exceptions Handling
5:22 - Live example
7:13 - Пример: Создаём проект в Visual Studio 2022 (.NET6)
Было бы круто еще:
1) Как работать с http, формирование запросов, куки, хедеры и т.д
2) Работа с кешем
3) Аутентификация и авторизация, роли
4) Горячие клавиши и фишки в IDE
Видос очень крутой, понятно всё с полу слова
Невероятно потрясён качеством контента. Автору моё почтение. Желаю всех благ в развитии канала!
Большое спасибо за качественную информацию! Очень помогает в профессиональном плане!
Очень качественный контент, мне 29, работаю первый год, свитчер из околоинженерной темы. Нашла ваши видео категорически полезными. Благодарю и желаю удачи
А зачем в ErrorDto есть поле StatusCode которое по сути дублирует HttpStatuscode, который в свою очередь внешняя система и так может получить из ответа?
Очень понятно, напишу глупо но такая подача материала интереснее чем читать msdn)
Шикарное видео и очень ценное. Все что надо есть. Правда ближе к концу я перестал понимать что за методы описываются, но это дефолт))
Очень познавательное видео! С разъяснением миллионом нюансов, спасибо за труды сенсей!
Спасибо за видео!
Great !
Спасибо большое за ваш труд!!!
Лучший👍💯 ждем еще инфу
А где использование переопределенного toString()?
Внимательный зритель на вес золота 🙂 Конвертация в json не требуются, так как этим занимается метод WriteAsJsonAsync() в HttpResponse. В видео я сделал это излишне. В исходниках проекта на GitHub я убрал лишние конвертации. Спасибо за внимательность! 👍
Приветствую. Склонировал ваш репозиторий, появился вопрос. При отправке запроса IDE тормозит на исключении и только потом проходит по пайплайну и обрабатывает исключение. Подскажите как это исправить?
Лучший, просто лучший.
Спасибо за ролик! Хотелось бы увидеть видео сравнение всех способов обработки исключений, в том числе и для mvc проекта. Допустим я использую реализацию для IExceptionFilter интерфейса.
Здравствуйте! Спасибо за видео, подскажите как Вы относитесь к обработки ошибок через var contextFeature = context.Features.Get(); После проверяем его на null и если фича содержит информацию по ошибкам то можно добавить соответствующие статусы с использованием swith
context.Response.StatusCode = contextFeature.Error switch
{
_ => StatusCodes.Status500InternalServerError
};
Я его использую в своих проектах. Подскажите какой способ лучше? Спасибо!
Здравствуйте!
Да, это еще один распространённый способ обработки исключений. Лично для меня, использование middleware проще. Возможно, существуют тонкие отличия в применении этих способов, но мне не приходилось сталкиваться с ними в решении реальных бизнес-задач. Если вам удобно пользоваться IExceptionHandlerFeature или в вашей команде так принято, то я не вижу в этом проблемы.
Если вам удастся узнать о важных отличиях, буду рад если поделитесь информацией 😊
Cool !!!
Thanks a lot. Content super usefully.
You are welcome 🙂
Я Сырым подписка +, спасибо автору
Привет Сырым! Добро пожаловать на борт! 🙂
@@codaza-channel 🤓🤓🤓
а в response в .net core 3.1 так же можно вставить дто?
Нет, метод расширения WriteAsJson работает для версий ASP.NET Core 6.0 и ASP.NET Core 5.0.
не ставил себе студию 2022, разрабы что, избавились от класса startup в шаблонах? И почему класс Program так странно выглядит, без объявления класса и код не в блоке, какие-то странные нововведения?
.NET 6 поищи, какие нововведения в нём, там есть ответы на твои вопросы, и нововведения эти совсем не странные, а логичные, удобные и понятные.
@@Позитивныйчел-ш3ж ок, понял
Хорошее видео) но как ловить эксепш если юзер не авторизован или например не имеет достаточно прав? Даже если в пайплайне встроить самым первым данный middleware ошибку он не перехватывает(
UPD: разобрался. Забыл что добавил кастомный AuthorizationHandler, и если в нем не выкидывать ошибку а просто фиксировать context.Fail(); то и try catch ничего не поймает
Ребятушки, пожалуйста НИКОГДА так не делайте как автор в этом видосе, НИКОГДА 1) не отключайте защиту от нуллреференсов (она заставляет вас учиться писать код правильно, понимать что вы пишите и защищает от 99% косяков, в которые вы без неё обязательно вляпаетесь) и 2) не обрабатывайте исключения не явным образом в миддлвэйре (вы так никонда не научитесь работать с ошибками, обработка исключений - НАМНОГО сложнее, чем просто логирование.. и для логирование исключений есть специальные инструменты и стандартные подходы, которые не имеют ничего общего с глобальной обработкой, вы легко можете потерять работу и получить волчий билет на всю жизнь, если не правильно обработаете всего одно, но очень важное, исключение.. а вы обязательно его не обработаете, если будете всегда ловить их глобально и не научитесь работать с ними правильно). Вы сами себя закопаете в яму говнокодерства в самом начале пути и выбраться из этой ямы потом будет очень очень сложно. Это самые вредные советы, какие только можно дать начинающим разработчикам. Я вообще сначала подумал, шо автор троллит просто, но нет, он серьёзно..
пример правильной обработки ошибок можно?
@@rar24 пример правильной обработки ошибок - это как минимум 1) определить точечно где и что может пойти не так и чем это грозит (в том числе проверить какие эксепшен могут кидать те методы, которыми вы пользуетесь и в каких ситуациях) 2) спланировать поведение системы в случае если что то пошло не так: откатить ранее сделанные изменения если возможно, заинфорсить политику ретрая (или вырубить серкут брейкер) если возможно 3) "упасть" как можно скорее (для чего и существует те самые эксепшены), что бы не допустить усугубления ситуации 4) сообщить в систему мониторинга о своём состоянии. Все это требует точечного подхода и понимания: как работает ваше приложение, что может пойти не так, что делать если что то пошло не так, в каких случаях ошибки можно игнорировать, а в каких нельзя. В случае каких то серьёзных ошибок у вас обязательно должны быть данные о том, что произошло и почему. Что бы можно было 1) постфактум исправить состояние, которое возникло по ошибке 2) проанализировать что пошло не так (Root cause analysis, RCA) и что сделать, что бы это не повторилось. Эксепшен нужно обязательно уметь отлавливать и вообще правильно с ними работать, это чрезвычайно полезный инструмент в любом рекавери и RCA.
Про нуллабле контекст я согласен с вами, его ни в коем случае не надо отключать, так ide будет вас заставлять писать проверки на null.
А вот по поводу глобальной обработки исключений, вроде в аспнет 7 исключения в запросах не крашат приложение, а логгируются по дефолту. Или я ошибаюсь?
@@sanchous177 дело же не в крашах, это как раз меньшая из проблем.. дело в навыках обработки ошибок
@@DF-ov1zmГде можно почитать о правильной обработке ошибок? Как насчёт функциональной обработки с помощью result pattern?
Почему метод UseMiddleware в пейплайн с хендлером вставляеться в самое начало? Почему не после авторизации? Или в конец? Или нету разницы вообще?
Потому что мы хотим отлавливать исключения, которые могут произойти в любом middleware выше по стеку вызова
Кто такой этот Roberto?
О Roberto очень мало информации. Известно лишь что он весьма ценный сотрудник для организации.
Автор, а вы случаем не переводили Пиратов карибского моря ? Первых 3 части
Увы 😞
ля, я уснул(
😥
#Codazastyle видео будет про что такое миделворе ?🤯
В этом ролике мы уже посмотрели на яркий пример использования middleware. Буду иметь ввиду, что хотелось бы поговорить о middleware отдельно.
Переопределяли ToString() для класса ErrorDto, но так и не воспользовались им 🥹
Да, вы правы. В комментариях ниже уже указывали на это. Повторюсь: Конвертация в json не требуются, так как этим занимается метод WriteAsJsonAsync() в HttpResponse. В видео я сделал это излишне. В исходниках проекта на GitHub я убрал лишние конвертации. Спасибо за внимательность! 👍