Bikeshed: Spliterator "fail-fast"

[Remi Forax]

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.
>
> 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().

>
>> Paul.
>>

Rémi