You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID> on 2017/05/27 13:40:01 UTC
[collections] Uniform null-safe methods in CollectionUtils
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.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] Uniform null-safe methods in CollectionUtils
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
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 <br...@apache.org>
To: Commons Developers List <de...@commons.apache.org>; Bruno P. Kinoshita <br...@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 <br...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] Uniform null-safe methods in CollectionUtils
Posted by Benedikt Ritter <br...@apache.org>.
Hello Bruno,
> Am 27.05.2017 um 15:40 schrieb Bruno P. Kinoshita <br...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org