Монго никогда не использовал. Но по коду, разве тут есть смысл указывать .ConfigureAwait(false)? Я это к тому что в ASP.NET Core это поведение по умолчанию. Источник
Медицинская страховка в Болгарии обязательна. Даже если вы не работаете извольте раз в месяц перечислять определенную сумму по страховой. Она хоть и не большая, честно говоря не знаю даже сколько, так как мне её оплачивает работодатель. Если вы студент, то её вам оплачивает универ, подозреваю что со школами тоже самое.
Почти со всем согласен кроме того что болгары не жалуются. Работаю программистом, живу в Пловдиве. Могу добавить что один из вариантов получить гражданство, это если у вас есть болгарские корни, там до определенного колена, и не обязательно по прямой линии.
Недавно была статья на хабре про сравнение async/await с корутинами го. Я не специалист, но заинтерисовало что такое корутины, и как они работают в Go. Если кто хорошо разбирается, возможно сможет улучшить статью, добавив в комментарии улучшунный код на го. Хочется понять с точки зрения асинхронности, когда лучше использовать корутины(то есть когда они будут быстрее). Сам лично набрел на пост в стековерфлоу, что хорошо спроектированное приложение, использующее потоки всегда будет быстрее файберов(именно они используется в основе корутин, если я правильно понял). Асинхронный код в c# писать легко, однако, если нужна будет скорость, можно запутатся во множестве деталей. Ну и поздравляю приверженцев Go с выходом новой версии.
First, FirstOrDefault, Single, SingleOrDefault очень хорошо улучшают читаемость кода. Согласен что надо искать компромисс между читаемостью и производительнотю, и шарпам это очень хорошо удаётся. Кстати говоря, если метод не обязательно должен быть исполнен мы можем воспользоваться элвис оператором ?.
По моему тема ушла в перекос о том как спастись/избавится/не использовать исключения. Я хотел показать лишь, что вместо использования object аргумента лучше всегда использовать generic, так как это спасает от упаковки.
Что касается самих исключений, то я придерживаюсь мнения, что исключения надо использовать только по необходимости, и где это возможно избегать. Это и в стандартной библиотеке встречается, например класс ReadOnlyCollection. Если вы его откроете и посмотрите на строку его объявления то увидите, что он наследует IList, у IList есть метод Add, однако ReadOnlyCollection, использует трюк который называется Explicit Interface Implementation. Получается вы защищены от вызова метода на инстанции класса, однако не защищены от вызова этого метода на интерфейсе.
Проектируя библиотеку, вы например не сможете избежать неправильного использования функции, и кто-нибудь да подаст аргумент null. Когда бизнес-логика не позволяет продолжить поток выполнения, лучше выбросить исключение, ну и задокументировать в каком случае оно будет выброшено.
И всего лишь 2 issue. Вот так действительно пример хорошо сделанной библиотеки.
Что касается самих исключений, то я придерживаюсь мнения, что исключения надо использовать только по необходимости, и где это возможно избегать. Это и в стандартной библиотеке встречается, например класс ReadOnlyCollection. Если вы его откроете и посмотрите на строку его объявления то увидите, что он наследует IList, у IList есть метод Add, однако ReadOnlyCollection, использует трюк который называется Explicit Interface Implementation. Получается вы защищены от вызова метода на инстанции класса, однако не защищены от вызова этого метода на интерфейсе.
Получается если мы хотим гарантировать невозможность удаления данных придется делать обязательную репликацию.