Hey Martin, -----Original Message-----
From: Martin Desruisseaux <[email protected]> Organization: Geomatys Reply-To: "[email protected]" <[email protected]> Date: Saturday, March 30, 2013 2:21 PM To: "[email protected]" <[email protected]> Subject: Re: On null collections >Hello Chris > >Le 30/03/13 21:28, Mattmann, Chris A (388J) a écrit : >>> In this context, it would be Collections.empty{Set|List}. The point was >>> that we could see a nuance between "no elements", and "elements can not >>> exist here in current context". In the first case, users can add >>> elements. In the second case, they can not. Returning a null value in >>> the second case would be a way to differentiate them. >> Well that's my point -- Collections.unmodifiableList [1] for example, >> handles the 2nd case well and would avoid having to return null (and >> the XML marshaling issue you mention below). Right? > >I don't see how? Collections.emptyList() can be seen as a special case >of Collections.unmodifiableList(...) with zero element. Is Collections.emptyList() returning a list that throws an exception when it's modified? If so, then I get what you mean: http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Collections.html#emp tyList() Yep I get it -- same thing, you're right. >I don't see >which difference Collections.unmodifiableList(...) could bring? (unless >the proposal is to return singleton containing the null element). Yeah that was sort of my proposal -- making a singleton to return the null element. > > >>> Returning Collections.empty{Set|List} means that it is not worth to >>> distinguish those two possibilities, which is a perfectly valid >>>decision >>> for keeping the API simpler. Eventually, the exception thrown by >>> Collection.add(...) could contains a message saying why elements can't >>> be added. >> Isn't that just replicating what [1] does? > >It would just replicate what Collections.emptyList() does, with the only >difference that the message in the exception would be different. +1 for me. > >The reason for that is that UnsupportedOperationException in the >collection framework are usually thrown for unmodifiable collections. >This happen when the metadata has been declared unmodifiable (the API >allows that). But in this particular case, the >UnsupportedOperationException would be thrown because a particular >property is mutually exclusive with another property, despite the >metadata being modifiable. Some choices are: > > 1. Ignore this subtle difference (Pro: simplest approach except for > XML. Con: users may be puzzled about why he can not add elements in > his modifiable metadata). > 2. Return null (Pro: simplest approach including for XML, except that > it requires more javadoc. Con: users who don't read javadoc may get > NullPointerException). > 3. Returns something that replicate Collections.emptyList() except for > the more accurate exception message. (Pro: as 1 without the puzzling > part). I've never been a fan of returning a null list, mainly b/c I'm the guy that usually does Method.getList().add(some new List element). ;) That said, 1-3 are all feasible to me, so whichever one you pick I'm +1 for. Thanks dude. Cheers, Chris
