Открыть список
Как стать автором
Обновить

Комментарии 11

Какой-то поток сознания. Ок, исключения это плохо, а как делать-то?

Показывать поле IsDisposed в принципе небезопасно, потому что, если CLR соберет мусор, можно словить Null reference.


Что?

Тут тоже делаем поле IsDisposed, но на этот раз делаем его с публичным гетером, чтобы человеку, использующему библиотеку не пришлось писать больше защитного кода.

Если метод Dispose был вызван, делаем return и дело с концом. Конечно, при повторном обращении к полю он получит nullref, потому что объект уже будет удален из памяти, но моя ли это проблема.


Что? Статическое поле будет доступно всё время жизни приложения. Публичное статическое поле != геттер, btw

Console.WriteLine($"{'2' + '2' — '2' }");
Взять, например, пользовательский инпут, который после обновления библиотеки начал мапиться в string вместо int, как раньше, а оператор (+) и математический оператор и оператор конкатенации.


Ничего не понял. «Как раньше» это как? Вы зачем чары складываете? Естественно в аутпут интерполируется результат математической операции

Так в примере еще и не string ни разу, а вовсе даже char.

C# я не люблю

Так, а зачем нам дальше читать ваш предвзятый поток мыслей. Хабр в микро блоги ЖЖ превращается
И под конец — операторы
Это точно про c#? Аж испугался, вдруг вправду новведения такие?
C# Interactive:
>true==1
(1,1): error CS0019: Оператор "==" невозможно применить к операнду типа «bool» и «int».

Смахнув пот со лба, ушел в нирванну.
Курильщик №1 делает Powershell

Код, написанный ниже, и правда написан каким-то курильщиком, но я так и не понял кто этот курильщик мог быть кроме автора статьи.


Показывать поле IsDisposed в принципе небезопасно, потому что, если CLR соберет мусор, можно словить Null reference.

Не вижу связи.


При повторном вызове Dispose или другого метода мы выкидываем исключение

Зачем ВЫ выкидываете тут исключение? В реальном коде повторный вызов Dispose — это пустая операция (какой она и должна быть согласно интерфейсу IDisposable).




Курильщик №2 делает RunspacePooll

Если метод Dispose был вызван, делаем return и дело с концом. Конечно, при повторном обращении к полю он получит nullref, потому что объект уже будет удален из памяти, но моя ли это проблема.

Всё ещё не вижу связи между вызовом Dispose и удалением объекта из памяти.




Здоровый человек использует библиотеку:

Получается, что в одном месте нужно обработать ObjectDisposedException, в другом NullReferenceException в третьем InvalidRunspacePoolStateException и все полно сюрпризов.

Посмотрю я как вы будете нетривиально обрабатывать NullReferenceException.


Некоторые исключения не предназначены для того, чтобы их можно было как-то обработать, единственный способ обработки тут — записать в лог или там отправить по email разработчику.




Теперь про ваш пример с чтением файла. Ваш вариант "до" имеет один минус — гонку между чтением файла, и любой другой программой, которая потенциально может этот файл удалить.


Второй вариант — правильный, в нём подобной гонки нет. Хотя лучше бы вместо FileNotFoundException ловить IOException, ведь отсутствие файла — не единственная неприятность, которая может случиться при чтении.


А третий вариант — это вариант курильщика, потому что мало того что там есть конка — так ещё и нет никаких причин выбрасывать NRE при отсутствии файла. И если вы этого не понимаете — вы и есть тот самый курильщик.

Да согласен с автором. CSharp он не любит. Наверное готовить не умеет, судя по коду.
С исключениями всё просто. Нужно придерживаться правила, что при нормальной работе пользователя исключение не будет выкинуто. Пользователь ввёл неправильные данные — возвращаем ошибку, пользователь ввёл некорректный пароль — вернули признак ошибки, сообщение. Отвалилось соединение сервера с бд — исключение, случилось переполнение — исключение. То есть исключения, это «исключительная ситуация». При таком подходе все исключения логгируются, они возникают редко, но всегда по делу.
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
Но, плохой, конечно, язык. Ну, ок…
Полностью соглашусь. Плюс:
— не понимает что такое исключение
— не знает что такое race condition
— не отличает implicit и explicit casting

Мне вдруг стало интересно, что бы автор написал про async/await.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.