Prev: Reflection accessing subclass
Next: java Date to c# ticks
From: Lew on 2 Mar 2010 19:08
Mike Schilling wrote:
>>>> boolean areListElementsUnique(List<?> l)
>>>> {
>>>> return l.size() == new HashSet<Object>(l).size();
>>>> }


laredotornado wrote:
>>> Winner! -

Lew wrote:
>> Don't forget to null-check the argument!

Tom Anderson wrote:
> The method already does that - if it's null, you get a
> NullPointerException.

Umm, the point of my comment was to *avoid* the NPE, duhh. Why cause trouble
for the method's client?

--
Lew
From: Mike Schilling on 2 Mar 2010 19:42
Lew wrote:
> Mike Schilling wrote:
>>>>> boolean areListElementsUnique(List<?> l)
>>>>> {
>>>>> return l.size() == new HashSet<Object>(l).size();
>>>>> }
>
>
> laredotornado wrote:
>>>> Winner! -
>
> Lew wrote:
>>> Don't forget to null-check the argument!
>
> Tom Anderson wrote:
>> The method already does that - if it's null, you get a
>> NullPointerException.
>
> Umm, the point of my comment was to *avoid* the NPE, duhh. Why cause
> trouble for the method's client?

Consistency with all of the Collections methods, which just throw NPEs.


From: Tom Anderson on 3 Mar 2010 15:24
On Tue, 2 Mar 2010, Lew wrote:

> Mike Schilling wrote:
>>>>> boolean areListElementsUnique(List<?> l)
>>>>> {
>>>>> return l.size() == new HashSet<Object>(l).size();
>>>>> }
>
> laredotornado wrote:
>>>> Winner! -
>
> Lew wrote:
>>> Don't forget to null-check the argument!
>
> Tom Anderson wrote:
>> The method already does that - if it's null, you get a
>> NullPointerException.
>
> Umm, the point of my comment was to *avoid* the NPE, duhh. Why cause trouble
> for the method's client?

I'm hoping that you're being sarcastic. Or that i've misunderstood - i
read your comment as suggesting that the method should null-check the
incoming argument.

The right thing for this method to do if passed a null argument is to
throw an exception. There is no uncertainty about that. And it already
does that, so no check is necessary.

tom

--
But in the week its like Urbino under the wise rule of Count Federico,
only with a better football team and the nations most pleb-infested
Waitrose. And shops selling size 12 stilettos. -- Jelb, on Holloway
From: Tom Anderson on 3 Mar 2010 15:27
On Mon, 1 Mar 2010, Joshua Cranmer wrote:

> On 03/01/2010 06:36 PM, Tom Anderson wrote:
>> if (cur.equals(prev)) return false;
>
> What if there are null entries in the list?

Then you are a bad man, and you do not deserve to be using my code!

If you do need to have nulls in the list, then you can use the
time-honoured and sorely-missed-from-the-standard library formula:

private static boolean equals(Object a, Object b) {
return (a != null) ? a.equals(b) : (b == null);
}

> This snippet also, of course, assumes that T is a comparable object (I
> believe Collections.sort fails if there's no comparator and T can't be
> cast to Comparable).

Certainly true. I should have typed the method accordingly, my apologies.

tom

--
But in the week its like Urbino under the wise rule of Count Federico,
only with a better football team and the nations most pleb-infested
Waitrose. And shops selling size 12 stilettos. -- Jelb, on Holloway
From: Mike Schilling on 3 Mar 2010 16:33
Tom Anderson wrote:
> On Tue, 2 Mar 2010, Lew wrote:
>
>> Mike Schilling wrote:
>>>>>> boolean areListElementsUnique(List<?> l)
>>>>>> {
>>>>>> return l.size() == new HashSet<Object>(l).size();
>>>>>> }
>>
>> laredotornado wrote:
>>>>> Winner! -
>>
>> Lew wrote:
>>>> Don't forget to null-check the argument!
>>
>> Tom Anderson wrote:
>>> The method already does that - if it's null, you get a
>>> NullPointerException.
>>
>> Umm, the point of my comment was to *avoid* the NPE, duhh. Why
>> cause trouble for the method's client?
>
> I'm hoping that you're being sarcastic. Or that i've misunderstood - i
> read your comment as suggesting that the method should null-check the
> incoming argument.
>
> The right thing for this method to do if passed a null argument is to
> throw an exception. There is no uncertainty about that. And it already
> does that, so no check is necessary.

Sometimes the check is necessary, of course. Consider
Collections.unmodifiableList(), for which a naive implementation goes
something like

public List unmodifaibleList(List list)
{
class UnmodifiableList implments List
{
private List list;

UnmodifiableList(List list)
{
this.lst = list;
}

public get(int i)
{
return list.get(i);
}

// etc.
}

return new UnmodifiableList(list);
}

That will work, but it's much beter for the UnmodifiableList constructor to
be

UnmodifiableList(List list)
{
if (list == null)
throw new NullPointerException();
this.lst = list;
}

so that the exception is thrown immediately rather than waiting until the
new list is first accessed.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: Reflection accessing subclass
Next: java Date to c# ticks