Ну не отхватишь NRE в том месте, где он падает, отхватишь в начале метода. В обоих случаях все равно полезешь смотреть StackTrace и исправлять баг.
Как бы да, nullable context пока форсированно не внедрен, но, во первых, никто не запрещает поставить соответствующий флаг компиляции, а во-вторых, он решают проблему на корню, вместо того чтобы писать тонны костылей в виде ThrowIfNull.
Я и не предлагаю вместо IOptions<MyServiceOptions> прокидывать IConfiguration, это же дичь. Достаточно простой дэтэошки в виде того же record MyServiceOptions. Ее мокать ваще проще простого.
Ну нет, "где и как лежит", если речь про конфиг-хранилище, то задача это достать и распарсить лежит на том, кому это хранилище принадлежит, обычно это исполняемая (exe) сборка. А если у вас "другой библиотеке" требуется какая-то конфигурация, то она должна "попросить" ее через свой интерфейс или тот же record.
Меня это вообще не парит, абсолютно. Зато меня парит, что я потом с кодом практически ничего сделать не могу, как раньше, так, видимо, и сейчас. Сделать новый await? Нельзя. Объявить константу? Нельзя. Новое расширение? Нельзя. Да хотя бы чортов Using в начало файла засунуть - нельзя блин! Хочешь менять код в рантайме - придется потом менять еще раз уже, когда уже приложуха остановится. Хотя проще сразу остановить.
Чтобы без проблем вызывать IDisposable.Dispose() несколько раз, необходимо поле _disposed
Это требование необходимо выполнять только в случае, если вы работаете напрямую с неуправляемым ресурсами и только если их повторный Dispose вызовет плохое поведение. Во всех остальных случаях (99%), когда ваш IDisposable класс использует IDisposable поля, это требование можно легко игнорировать.
Просмотры сами себя не сделают.
Конфигурация - это хорошо, но причём тут ASP.NET (Core или не Core), совсем не понятно.
Я бы чуть по-другому перефомулировал:
"Потому что
FileInfoне умеет в сравнение".По той же причине он не будет работать без кастомного компаратора в словарях, хештаблицах и прочем добре дотнета.
а поподробнее пример-пожелание можно?
Тоже ожидал, что звук будет именно СПРЯТАН (как обещает заголовок), в картинку, а не вот этот вот ужас.
Спасибки.
Подскажите, а где можно такие симпатишшные провода в силиконовой оплетке прикупить?
Ну я и говорю, их же собственные трудности.
Ну не отхватишь NRE в том месте, где он падает, отхватишь в начале метода. В обоих случаях все равно полезешь смотреть StackTrace и исправлять баг.
Как бы да, nullable context пока форсированно не внедрен, но, во первых, никто не запрещает поставить соответствующий флаг компиляции, а во-вторых, он решают проблему на корню, вместо того чтобы писать тонны костылей в виде
ThrowIfNull.Я и не предлагаю вместо
IOptions<MyServiceOptions>прокидыватьIConfiguration, это же дичь. Достаточно простой дэтэошки в виде того жеrecord MyServiceOptions. Ее мокать ваще проще простого.Группировка, потом ToList, потом ToList, да и зачем вообще List возвращать в коде; сложность — что по CPU, что по памяти, в итоге хорошо если O(3N)?
Их же собственные половые трудности. В свое время обновление было беплатным.
Опции как-то сильно переоценены. Из полезного разве что монитор горячих изменений. Но он как раз в configure service не нужен.
Ну нет, "где и как лежит", если речь про конфиг-хранилище, то задача это достать и распарсить лежит на том, кому это хранилище принадлежит, обычно это исполняемая (exe) сборка. А если у вас "другой библиотеке" требуется какая-то конфигурация, то она должна "попросить" ее через свой интерфейс или тот же record.
лучше бы добавили поддержку record-ов для конфигурационных моделей, делов-то конструктор вычитать.
Да и смысл, если есть nullable context.
Мен еще интересно, а обычное автоформатирование кода для Dictionary initializerов они наконец сделают в 2022 году?
Меня это вообще не парит, абсолютно. Зато меня парит, что я потом с кодом практически ничего сделать не могу, как раньше, так, видимо, и сейчас. Сделать новый await? Нельзя. Объявить константу? Нельзя. Новое расширение? Нельзя. Да хотя бы чортов Using в начало файла засунуть - нельзя блин! Хочешь менять код в рантайме - придется потом менять еще раз уже, когда уже приложуха остановится. Хотя проще сразу остановить.
Это требование необходимо выполнять только в случае, если вы работаете напрямую с неуправляемым ресурсами и только если их повторный Dispose вызовет плохое поведение. Во всех остальных случаях (99%), когда ваш IDisposable класс использует IDisposable поля, это требование можно легко игнорировать.
А смысл это делать без паузы? Я уверен, там по факту ставится пауза на небольшое время автоматически