This protection concept sounds perfectly rational, until you think of
other obvious things that do similar things to protect the coder.
myLong.equals(myString) doesn't throw an exception for instance, it just
return false.
but then you never know that you have a problem in your code and just
blindly go along using it seemingly working fine.
Similarly, given that collection.addAll(null) throws, papering over that
fact with CollectionUtils might do more harm than good.
On 05/19/2018 09:10 PM, Gary Gregory wrote:
On Sat, May 19, 2018 at 4:47 AM, sebb <seb...@gmail.com> wrote:
On 18 May 2018 at 20:34, Gary Gregory <garydgreg...@gmail.com> wrote:
Hi All:
A lot of methods in CollectionUtils are not null-safe and are documented
as
such in Javadoc with throwing NPEs.
I'd like to change that.
To what?
For example, this should not cause an NPE:
collectionA = new ArrayList();
CollectionUtils.addAll(collectionA, (Integer[]) null);
Gary
The change is behavioral and BC would be preserved.
Thoughts?
It depends on the method whether a null parameter makes sense or not.
In some cases it may be confusing if null is accepted.
And what is meant by a null parameter.
In any case, any such changes need a big warning in the release notes.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
