IEnumerator specification inconsistency?

  • Thread starter Thread starter Adam Badura
  • Start date Start date
A

Adam Badura

In MSDN (August 2006) in the specification of IEnumerator.Current there
is word on exceptions. InvalidOperationException shall be thrown in case
"The collection was modified after the enumerator was created.". But in the
remarks section it can be read that "If the collection is modified between
MoveNext and Current, Current returns the element that it is set to, even if
the enumerator is already invalidated."
For me both this sentances seem to be contradictory. Or am I mistaken?
Also another intersting thing. IEnumerator<T> does not specify
exceptions at all. In remarks section it says only when Current is
undefined.

Framework doesn't seem to do checks at all.

Adam Badura
 
Adam said:
In MSDN (August 2006) in the specification of IEnumerator.Current there
is word on exceptions. InvalidOperationException shall be thrown in case
"The collection was modified after the enumerator was created.". But in the
remarks section it can be read that "If the collection is modified between
MoveNext and Current, Current returns the element that it is set to, even if
the enumerator is already invalidated."
For me both this sentances seem to be contradictory. Or am I mistaken?
Also another intersting thing. IEnumerator<T> does not specify
exceptions at all. In remarks section it says only when Current is
undefined.

Framework doesn't seem to do checks at all.

Adam Badura
Click to expand...

Yes, that is inconsistent. In the 1.1 version of the documentation, it's
consistent:

http://msdn2.microsoft.com/en-us/library/system.collections.ienumerator.current(VS.71).aspx

The implementation seems to follow the 1.1 version of the documentation.
If you for example look at the code for List<T>.Enumerator<T>.Current,
it only returns the current element without checking the list object
version:

public T Current {
get {
return this.current;
}
}
 
Back
Top