Hi Benedikt,
Sounds good to me. There is a user interested in that issue too, so will check
what he suggests as well. Will ping Thomas Neidhart too to check what he thinks
as I think he was driving the changes in the last releases of collections.
CheersBruno
From: Benedikt Ritter <brit...@apache.org>
To: Commons Developers List <dev@commons.apache.org>; Bruno P. Kinoshita
<brunodepau...@yahoo.com.br>
Sent: Monday, 5 June 2017 10:44 PM
Subject: Re: [collections] Uniform null-safe methods in CollectionUtils
Hello Bruno,
> Am 27.05.2017 um 15:40 schrieb Bruno P. Kinoshita
> <brunodepau...@yahoo.com.br.INVALID>:
>
> Hi,
>
> COLLECTIONS-600 [1] received a pull request [2] to make a method in
> CollectionUtils null-safe. Before merging it, I decided to check what was the
> current approach in this class for handling null in methods.
>
> COLLECTIONS-604 [3] contains the CSV file with the methods names and current
> behaviour. TL;DR "Currently, there are 65 public methods in
> `CollectionUtils`. And 53 without the deprecated ones. Out of these, 24
> handle `null` arguments. The remaining methods throw a `NullPointerException`
> (NPE) at some part of its code."
>
> There are also cases where the javadocs suggest a NPE if any of the arguments
> is null, but there are no if's checking if it is null, instead it relies on a
> call to a member of the object to raise the NPE, or the intriguing case of
> CollectionUtils.isEmpty(null) which returns true, and
> CollectionUtils.isFull(null) which throws NPE (even though there is a
> isNotEmpty, I'd expect isEmpty and isFull to be in some way related and have
> similar behaviour).
>
> Should we just work method per method and make it null-safe if necessary, or
> should we define a common behaviour to all of its methods? I can see some
> advantages of the latter for users, but am still not sure which approach to
> take here.
Nobody seems to have an opinion on this issue so you should start implementing
your preference.
Regards,
Benedikt
>
> Cheers
> Bruno
>
> [1] https://issues.apache.org/jira/browse/COLLECTIONS-600
> [2] https://github.com/apache/commons-collections/pull/22
> [3] https://issues.apache.org/jira/browse/COLLECTIONS-604
>
> ---------------------------------------------------------------------
> 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
