Bikeshed: Spliterator "fail-fast"

[Remi Forax]

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 :)

>
> Paul.

Rémi