Bikeshed: Spliterator "fail-fast"

[Paul Sandoz]

On Jul 1, 2013, at 4:45 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 07/01/2013 03: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
>> 
>> ?
> 
> fail-slow :)
> 

:-)

Although when going parallel it might not be slower than that of using an iterator over the source.

Paul.