Здравствуйте, Sinix, Вы писали:

S>Я конечно всё понимаю, но этого я не понимаю.
S>Ссылаться на FDG и рекомендовать то, чего там нет — это уже перебор

А можно подробнее? А то критиковать что-то, чего автор не имел ввиду — это уже перебор

ST>>Согласно Framework Design Guildelines ... метод этот синхронный и последующий вызов любого другого экземплярного метода должен падать с ObjectDisposeException (двойнов вызов метода Dispose допустим, исключения быть не должно).

S>В гадлайнах кое-что другое написано:
S>

S>DO throw an ObjectDisposedException from any member that cannot be used after the object has been disposed of.

S>Выделенный текст важен.

Я подхожу к этому со стороны ООП (сори). И метод Dispose логически разрушает инвариант созданного объекта. Наличие этого метода говорит о том, что инвариант (чем бы он не был, ресурсом, логическим или физическим состоянием и т.п.) инициализируется в конструкторе, но разрушается не при недоступности объекта (и последующем пристреливании объекта с помощью GC). Исходя из вопроса топикстартера не совсем ясно, чем этот инвариант является, но, мое предположение было таким, что последующий вызов метода GetNext меняет поведение после вызова Dispose и я рассматривал этот случай, как тот, что попадает под выделенный важный текст.

Вообще, выделенный важный текст довольно стремный. Почему? Да потому что он раскрывает детали реализации. Для меня — простого клиента класса, любое обращение к любому члену потенциально означает, что я дергаю "member that cannot be used after the object has been disposed". Это же детали реализации, скрытые от меня. Верно? Именно поэтому я придерживаюсь более простого правила, которое противоречит выделенному важному тексту, а именно: любой член Disposable класса (кроме метода Dispose) должен бросать исключение при обращении к нему после вызова Dispose. И это даже может быть характерно всяким property getter-ам, поскольку в один момент их реализация может измениться и вместо обращения к свойству я начну обращаться к внутреннему состоянию, которое уже разрушено.

S>Ну и см. описание самого метода:
S>

S> By convention, this method is used for all tasks associated with freeing resources held by an object, or preparing an object for reuse.

S>Пример использования Disposable для асинхронных операций — см Rx. Например, OnNext() вот тут.

Я не говорил об использовании Dispose для асинхронных операций, я писал о вреде "асинхронной" реализации метода Dispose, которая ставит что-то в очередь. И вот это, ИМХО, очень и очень плохо, поскольку нарушает принцип наименьшего удивления, согласно которому состояние объекта изменяется сразу же после вызова метода, а не когда-то позже.