Bikeshed: Spliterator "fail-fast"

[Mike Duigou]

(Sorry for the delayed response. This is the final thread I processed in digging out of my post-Holiday email deluge)

On Jul 9 2013, at 16:02 , Remi Forax wrote:

> On 07/08/2013 04:10 AM, David Holmes wrote:
>> Hi Paul,
>> 
>> On 1/07/2013 11:46 PM, Paul Sandoz wrote:
>>> Hi,
>>> 
>>> The Spliterator doc states:
>>> 
>>>  * <p><a name="binding"/>A Spliterator that does not report {@code IMMUTABLE} or
>>>  * {@code CONCURRENT} is expected to have a documented policy concerning:
>>>  * when the spliterator <em>binds</em> to the element source; and detection of
>>>  * structural interference of the element source detected after binding.
>>> ...
>>>  * After binding a Spliterator should, on a best-effort basis, throw
>>>  * {@link ConcurrentModificationException} if structural interference is
>>>  * detected.  Spliterators that do this are called <em>fail-fast</em>.
>>> 
>>> As Mike pointed out to me "fail-fast" is not accurate since the implementations for bulk traversal, specifically forEachRemaining, can throw a CME after traversal has completed.
>>> 
>>> - fail-finally
>>> - fail-ultimately
>>> - fail-eventually
>>> 
>>> ?
>> 
>> Nothing. It is either fail-fast or else you don't say anything.

Still throw the CME? After the fact would seem to be better than not at all. If a CME might be thrown we should mention it.

>> 
>> Any definition of fail-fast for Spliterator should be consistent with that of Iterator.
>> 
>> David
> 
> David, I agree with you, two semantics is too complex here.
> 
> Anyway, playing the devil advocate, most implementation of Iterator are not as fail-fast
> as they could, they don't check the collection modification in hasNext() but only in next().

I believe that only checking in next() is reasonable compromise for best-effort without unduly impairing performance. 

One thing to note is that some CME are generated in defensive conditions where the data structure is attempting to avoid self-mutilation of ArrayIndexOutOfBoundsException, NPE, etc. separate from modCount checks. I would expect that Spliterators et al might have similar defensive checks even if they don't do per-elment modCount tracking.

Mike