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. I don't see
which difference Collections.unmodifiableList(...) could bring? (unless
the proposal is to return singleton containing 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.
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).
Martin
