#капитану_на_заметку

Всем привет!

Как здорово генерировать исключения в секции try и ловко ловить их в секции catch 🌈 Одно удовольствие работать с синхронным кодом. Мрачнее дела обстоят при работе с асинхронным кодом. Это как классическая механика и квантовая физика: в асинхронном коде постоянно возникает "квантовая запутанность" и работает там всё по другим законам 🤯

Взгляните на два примера на картинке. В первом варианте мы не ожидаем (await) результата выполнения Task.FromException(), а сразу возвращаем Task, что приводит к несрабатыванию блока catch. Во втором примере мы решаем эту проблему ожидая результат выполнения Task.FromException().

Такая ситуация может приводить к аварийному завершению всего приложения и отыскать причины будет очень непросто. Будьте внимательны!

Поиграться с примером можно по ссылке: https://clck.ru/hcRSc

+1 к тонкостям работы с асинхронным кодом ✅

Всем хороших выходных!

Всем привет!

Последние пару дней я занимался оптимизацией производительности высоконагруженного микросервиса, который обрабатывает финансовые транзакции. Микросервис написан весьма качественно и, честно говоря, некоторое время я был в затруднительном положении, так как казалось, что оптимизировать решительно нечего. Однако, наряду с другими небольшими улучшениями, один фактор всё же позволил мне добиться поставленных целей. Поэтому я рад поделиться этим знанием с вами 🙂

Уверен, что в самых разных источниках, вы читали, что в качестве параметра метода следует использовать IEnumerable, если не требуется функциональность IList или List. Кроме того, хорошей практикой всегда считается следование принципу: Принимай наиболее общее (generic), а возвращай наиболее частное (specific). Это важные принципы, которых стоит придерживаться в подавляющем большинстве случаев. Всё же, бывают ситуации, в которых от этих принципов приходится отступать.

Как вы думаете, есть ли разница в определении параметра метода как IEnumerable или List?

Короткий ответ: да, разница есть.

Дело в том, что, когда параметр метода определяется через интерфейс IEnumerable, в списке выполняются операции boxing и unboxing, что неизбежно ведет к лишним аллокациям в оперативной памяти. Как следствие, мы получаем потери в производительности. Иногда не критичные, а иногда вполне ощутимые. Таким образом, поменяв только тип параметра, мы можем существенно поднять производительность без внесения значительных правок. В моём случае, поставленные цели были достигнуты, и задача решена.

+1 к производительному коду ✅

Всем хороших выходных!

#капитану_на_заметку

#капитану_на_заметку

Всем привет!

Спешу поделиться с вами интересным практическим случаем работы со строками. Недавно мне довелось работать с одним из австрийских сервисов обработки сообщений из различных мессенджеров (WhatsApp, Viber и пр). Ребята собирают аналитическую статистику по отправляемым сообщениям и столкнулись с тем, что данные в этой статистике, время от времени, искажались непонятным образом.

Я проанализировал исходный код сервиса и обнаружил, что проблема в подсчёте длины строки сообщений. Разработчик сервиса воспользовался свойством Length у экземпляра класса String. Это решение было логично и казалось единственно верным. Проблема в том, что люди часто используют Emoji в своих сообщениях и 1 символ Emoji не равен длине одного символа, так как для их кодировки используется Unicode.

Для правильного сбора статистки требовалась именно посимвольная длина строки. Свойство LengthInTextElements (класс StringInfo) решает именно эту задачу.

+1 к опыту работу со строками ✅

Всем хороших выходных!

#капитану_на_заметку

Я никогда не делаю исключений. Исключения опровергают правило.

Артур Конан Дойл

Всем привет!

Тема правильной работы с исключениями (exceptions) весьма холиварна и едва ли подлежит окончательному разрешению 🙂 Но сегодня я хочу обратить вниманием на другое — на цену. Цену использования исключений. Работаете вы с ними правильно или неправильно, держите в голове что за это придётся заплатить цену. При работе с большими массивами данных это может привести к значительной деградации производительности вашего приложения. Я не говорю о том, что мы не должны генерировать исключения, но разработчик обязан понимать, что выбрасывать исключения без аргументированной необходимости — плохая идея.

Руководствуйтесь простым правилом: Исключения для исключительных ситуаций.

Вы знаете как обработать исключение? Просто сделайте это без лишних throw 😉

+1 к исключительному коду ✅

Всем хороших выходных!