On 12/22/10 03:07 PM, Rémi Forax wrote:
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 ?
Would it make sense to simply swallow the exception ( do nothing ) and
continue with the next element? Clearly if contains() throws and
Exception then the collection does not contain the given element?
-Chris.
-Chris.
Rémi
