Bikeshed: Spliterator "fail-fast"

[David Holmes]

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

> Paul.
>