Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated]

[Rémi Forax]

Hi Chris,

On 12/22/2010 02:45 PM, Chris Hegarty wrote:
> Mike,
>
> On 12/21/10 09:38 PM, Mike Duigou wrote:
>> Thanks. That's an important clarification to include. Here's the 
>> revised text:
>>
>>       *
>>       *<p>Care must also be exercised when using collections that do 
>> not permit
>>       * calling the {@code contains} method with a {@code null} 
>> value. If either
>>       * collection does not permit {@code contains(null)} then both 
>> collections
>>       * must not contain {@code null} values.
>>       *
>>
>> and the @throws text:
>>
>>       * @throws NullPointerException if either collection is {@code 
>> null}. May
>>       * also be thrown if one collection contains a {@code null} 
>> value and the
>>       * other collection does not permit {@code contains(null)}.
>
> My concern with this revised wording is that you are now specifying 
> that the implementation must use contains() ( and not be implemented 
> using a different strategy ). I guess an alternative implementation is 
> unlikely, but this does appear overly restricting.
>
> I wonder if its really necessary to add text to the NPE. A cautionary 
> note may be sufficient. We could also throw ClassCastException, but 
> there is no mention of it in the spec.
>
> Sorry for being a pain about this, I'm just concerned with adding 
> overly restricting spec.
>
> Have we thought about catching/swallowing these exceptions?

What do you want to do in the catch block ?

>
> -Chris.


Rémi