Comments 11
Показывать поле IsDisposed в принципе небезопасно, потому что, если CLR соберет мусор, можно словить Null reference.
Что?
Тут тоже делаем поле IsDisposed, но на этот раз делаем его с публичным гетером, чтобы человеку, использующему библиотеку не пришлось писать больше защитного кода.
Если метод Dispose был вызван, делаем return и дело с концом. Конечно, при повторном обращении к полю он получит nullref, потому что объект уже будет удален из памяти, но моя ли это проблема.
Что? Статическое поле будет доступно всё время жизни приложения. Публичное статическое поле != геттер, btw
Console.WriteLine($"{'2' + '2' — '2' }");
Взять, например, пользовательский инпут, который после обновления библиотеки начал мапиться в string вместо int, как раньше, а оператор (+) и математический оператор и оператор конкатенации.
Ничего не понял. «Как раньше» это как? Вы зачем чары складываете? Естественно в аутпут интерполируется результат математической операции
C# я не люблю
Так, а зачем нам дальше читать ваш предвзятый поток мыслей. Хабр в микро блоги ЖЖ превращается
И под конец — операторыЭто точно про c#? Аж испугался, вдруг вправду новведения такие?
C# Interactive:
Смахнув пот со лба, ушел в нирванну.
Курильщик №1 делает Powershell
Код, написанный ниже, и правда написан каким-то курильщиком, но я так и не понял кто этот курильщик мог быть кроме автора статьи.
Показывать поле IsDisposed в принципе небезопасно, потому что, если CLR соберет мусор, можно словить Null reference.
Не вижу связи.
При повторном вызове Dispose или другого метода мы выкидываем исключение
Зачем ВЫ выкидываете тут исключение? В реальном коде повторный вызов Dispose — это пустая операция (какой она и должна быть согласно интерфейсу IDisposable).
Курильщик №2 делает RunspacePooll
Если метод Dispose был вызван, делаем return и дело с концом. Конечно, при повторном обращении к полю он получит nullref, потому что объект уже будет удален из памяти, но моя ли это проблема.
Всё ещё не вижу связи между вызовом Dispose и удалением объекта из памяти.
Здоровый человек использует библиотеку:
Получается, что в одном месте нужно обработать ObjectDisposedException, в другом NullReferenceException в третьем InvalidRunspacePoolStateException и все полно сюрпризов.
Посмотрю я как вы будете нетривиально обрабатывать NullReferenceException.
Некоторые исключения не предназначены для того, чтобы их можно было как-то обработать, единственный способ обработки тут — записать в лог или там отправить по email разработчику.
Теперь про ваш пример с чтением файла. Ваш вариант "до" имеет один минус — гонку между чтением файла, и любой другой программой, которая потенциально может этот файл удалить.
Второй вариант — правильный, в нём подобной гонки нет. Хотя лучше бы вместо FileNotFoundException ловить IOException, ведь отсутствие файла — не единственная неприятность, которая может случиться при чтении.
А третий вариант — это вариант курильщика, потому что мало того что там есть конка — так ещё и нет никаких причин выбрасывать NRE при отсутствии файла. И если вы этого не понимаете — вы и есть тот самый курильщик.
console.log('2'+'2'-'2');
Дизайнеры JS посчитали, что отдельный оператор сложения и отдельный оператор конкатенации не нужны, поэтому делать математику на JS небезопасно.
Источником этого бага в JS является неявное приведение типа string к типу int посредством оператора. Так лишний сахар становится багом.
Так и не смог предположить, на какую проблему (баг), в разрезе своего поста, Вы пытаетесь указать. Не могли бы прояснить?
я читал файл по-старому:
if (File.Exists(txt)) return;
string readText = File.ReadAllText(txt);
Но после просмотра видео я начал делать по-новому:
try
{
string readText = File.ReadAllText(txt);
}
catch (System.IO.FileNotFoundException)
{
Console.WriteLine("File was not found");
}
}
Это, на самом деле, совершенно неуместный сарказм — подходы неэквивалентные. В первом случае вполне может статься так, что файл будет удален ровно после того, как вы получили FileExists = true и до того, как вы станете его читать. Так что вы все равно получите ошибку, несмотря на то, что вроде как наличие файла проверили. Второй же подход покроет и этот случай тоже.
Да, и там отрицание пропущено.
1. Автор не любит C#
2. Не понимает как работает управление памятью и GC в .NET
3. Не понимает отличие static полей от полей экземпляра
4. Не понимает различие между деструктором и IDisposable
5. Не знает как правильно реализуется disposable pattern, который в .NET существует еще с версии 1.0
6. Не отличает string от char
Но, плохой, конечно, язык. Ну, ок…
«Пишите код по-новому (тм)»