Best way to check if all elements in a List are unique
in [Java Help]
|
From: Lew on 9 Mar 2010 07:25 Lew wrote: >>> As Mike pointed out, some action may be needed upon discerning a >>> null. To his example, for example, I'd add logging in some >>> scenarios. The method may be one whose contract is to deliver some >>> default value, such as Mike's suggestion for the OP's case >>> >>> boolean areListElementsUnique(List<?> l) >>> >>> that a null argument be deemed trivially as containing no duplicate >>> elements. Mike Schilling wrote: > That wasn't my suggestion. Oops, I didn't intend that misattribution. I meant that the method was your suggestion. Sorry about that, chief. The point is that it depends on the required contract. Some apps may wish to consider the empty list (including null) as trivially not violating the uniqueness constraint. It isn't necessarily an error that the list be null. And even if it is, as you yourself pointed out you'll wish to handle it at the point of detection, and I add, at the least you'll want to log it and quite possibly wrap in a different exception, so it's not possible from one's throne to decree for all and sundry that they must accept the implicit NPE willy-nilly. Contrary to Tom's [sic] pronouncement, there very well may need to be a null check even with a rethrow. -- Lew
From: Mike Schilling on 9 Mar 2010 10:33 Lew wrote: > > The point is that it depends on the required contract. Some apps may > wish to consider the empty list (including null) as trivially not > violating the uniqueness constraint. It isn't necessarily an error > that the list be null. > And even if it is, as you yourself pointed out you'll wish to handle > it at the point of detection, and I add, at the least you'll want to > log it and quite possibly wrap in a different exception, This I doubt. The stanndard way to signal an illegally null argument is to throw an NPE. You see this all through the Java system classes, and in particular throughout the collections hierarchy. > so it's not > possible from one's throne to decree for all and sundry that they > must accept the implicit NPE willy-nilly. Contrary to Tom's [sic] > pronouncement, there very well may need to be a null check even with > a rethrow.
From: Tom Anderson on 9 Mar 2010 18:30 On Tue, 9 Mar 2010, Lew wrote: > Lew wrote: >>>> As Mike pointed out, some action may be needed upon discerning a >>>> null. To his example, for example, I'd add logging in some >>>> scenarios. The method may be one whose contract is to deliver some >>>> default value, such as Mike's suggestion for the OP's case >>>> >>>> boolean areListElementsUnique(List<?> l) >>>> >>>> that a null argument be deemed trivially as containing no duplicate >>>> elements. > > Mike Schilling wrote: >> That wasn't my suggestion. > > Oops, I didn't intend that misattribution. I meant that the method was your > suggestion. > > Sorry about that, chief. > > The point is that it depends on the required contract. Some apps may wish to > consider the empty list (including null) as trivially not violating the > uniqueness constraint. I agree that some might. But i cannot agree that they should. All that is required for evil to triumph, i need not remind you, is for good programmers to write code that tolerates nulls. > It isn't necessarily an error that the list be null. > > And even if it is, as you yourself pointed out you'll wish to handle it > at the point of detection, I will interject quietly to say that Mike's point about detecting nulls early and dispatching them promptly, rather than waiting for the inevitable spooky NPE at a distance, was spot on, and i'm a fool for not having thought of it. > and I add, at the least you'll want to log it True. Logging is to an extent orthogonal to throwing exceptions, and there are certainly cases where you want to do both. > and quite possibly wrap in a different exception, so it's not possible > from one's throne to decree for all and sundry that they must accept the > implicit NPE willy-nilly. Contrary to Tom's [sic] pronouncement, there > very well may need to be a null check even with a rethrow. Alright. But returning a value is not on. The point about throwing a more specific exception is interesting. In general, if a method gets a duff argument, we throw an IllegalArgumentException. But where it's duff because it's null, we throw NullPointerException. And where it's an index that's out of bounds, we throw IndexOutOfBoundsException. Why do we make those special cases? Should we? Or should we reserve those for the VM, and always throw IllegalArgumentException? Should NPE and IOOBE be subclasses of IAE? Or should we have a whole range of more precise exceptions to throw? I rarely see new subclasses of RuntimeException defined for this purpose; should we be more keen on doing that? tom -- The literature is filled with bizarre occurrances for which we have no explanation
From: Mike Schilling on 9 Mar 2010 22:36 Tom Anderson wrote: > I will interject quietly to say that Mike's point about detecting > nulls early and dispatching them promptly, rather than waiting for the > inevitable spooky NPE at a distance, was spot on, and i'm a fool for > not having thought of it. Don't say that. I don't want to be a fool every time you think of something I overlooked.
From: Volker Borchert on 9 Mar 2010 21:59
Tom Anderson wrote: > Should NPE and IOOBE be subclasses of IAE? I don't think so. In some cases, they might refer to an object's internals and IllegalStateException might seem more appropiate. -- "I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy(a)ncc1701.starfleet.fed> "I'm a mechanic, not a doctor." Volker Borchert <v_borchert(a)despammed.com> |