You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2020/02/23 01:25:40 UTC
[lang] NPE vs IAE
I would like to do the same in Lang as with Collections (see below.)\
We currently perform checks like:
Validate.isTrue(foo != null, ...)
Which should be IMO:
Validate.notNull(foo, ...);
The difference being that the former throws IAE and the later NPE.
As with [collections], my argument is the same, the JRE uses
Objects.requireNonNull() to throw an NPE, so I'd like to keep normalizing
on that.
Gary
---------- Forwarded message ---------
From: Gary Gregory <ga...@gmail.com>
Date: Tue, Dec 10, 2019 at 9:59 AM
Subject: Re: [collection] NPE vs IAE in
org.apache.commons.collections4.CollectionUtils
To: Commons Developers List <de...@commons.apache.org>, Bruno P. Kinoshita <
brunodepaulak@yahoo.com.br>
FTR, using requireNonNull is also an 'Effective Java' recommendation.
Gary
On Thu, Dec 5, 2019 at 4:54 PM Bruno P. Kinoshita
<br...@yahoo.com.br.invalid> wrote:
> +1 for NPE
>
> On Friday, 6 December 2019, 5:22:34 am NZDT, Gary Gregory <
> garydgregory@gmail.com> wrote:
>
> Hi All:
>
> org.apache.commons.collections4.CollectionUtils contains a mix of checking
> for null inputs by throwing NullPointerExceptions in some methods and
> IllegalArgumentExceptions in others.
>
> I propose we standardized to NPE simply because the JRE provides
> Objects.requireNonNull() just for this purpose.
>
> Gary
>
Re: [lang] NPE vs IAE
Posted by Gilles Sadowski <gi...@gmail.com>.
Le jeu. 5 mars 2020 à 19:04, Peter Verhas <pe...@verhas.com> a écrit :
>
> Just my 2c:
>
> When you have an assertion in the code that throws an exception, be it NPE
> or IAE then your code is less prone to errors during maintenance. In that
> case, the assertion is there is the code, kind of documenting it. If the
> assertion is not there with the reasoning that the subsequent code is
> throwing an NPE anyway then later a code change may alter the behavior,
> which may not be desired, and/or followed by the documentation.
>
> In my opinion, these assertions serve documentation purposes and are an
> exceptional example when the "shorter code is more readable" law does not
> apply. Also, Objects.requireNonNull has a version that can contain a nice
> message that is absolutely valuable for the caller. (I think, this was
> already discussed in detail.)
>
> The only reason I cannot argue with is performance if it was properly
> measured in the relevant desired use cases and the measurement proves that
> the assertions pose significant performance cost.
And it was my sole point.
I obviously agree that more info is nicer, and easier to
maintain.
Gilles
>
> Regards,
> Peter
>
>
> On Thu, Mar 5, 2020 at 4:12 PM sebb <se...@gmail.com> wrote:
>
> > On Wed, 4 Mar 2020 at 14:20, Gilles Sadowski <gi...@gmail.com> wrote:
> > >
> > > Le mer. 4 mars 2020 à 15:16, sebb <se...@gmail.com> a écrit :
> > > >
> > > > On Wed, 4 Mar 2020 at 14:09, Gary Gregory <ga...@gmail.com>
> > wrote:
> > > > >
> > > > > IMO, until we are all on Java 14 and benefit from its more detailed
> > NPE
> > > > > message, we need to call Validate.notNull _with a message_ that says
> > what
> > > > > variable blew up.
> > > >
> > > > +1
> > > >
> > > > That is another good point.
> > > >
> > > > Unless one has access to the exact same version of the source, it can
> > > > be very tricky to tell which variable has caused the NPE.
> > > > The same applies to letting the JRE throw the NPE.
> > >
> > > Are you assuming that one should be able to fix the bug
> > > without the stack trace?
> >
> > No, I'm saying that the stack trace is not much use without having
> > access to the exact version of the source that was used to create the
> > binary.
> > An approximate line number may not be sufficient to identify the variable.
> >
> > > If so, I fail to see how having the name of a variable will
> > > make it less tricky to locate the cause of the issue...
> >
> > See above.
> >
> > > Gilles
> > >
> > > >> [...]
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
> --
> Peter Verhas
> peter@verhas.com
> t: +41791542095
> skype: verhas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] NPE vs IAE
Posted by Peter Verhas <pe...@verhas.com>.
Just my 2c:
When you have an assertion in the code that throws an exception, be it NPE
or IAE then your code is less prone to errors during maintenance. In that
case, the assertion is there is the code, kind of documenting it. If the
assertion is not there with the reasoning that the subsequent code is
throwing an NPE anyway then later a code change may alter the behavior,
which may not be desired, and/or followed by the documentation.
In my opinion, these assertions serve documentation purposes and are an
exceptional example when the "shorter code is more readable" law does not
apply. Also, Objects.requireNonNull has a version that can contain a nice
message that is absolutely valuable for the caller. (I think, this was
already discussed in detail.)
The only reason I cannot argue with is performance if it was properly
measured in the relevant desired use cases and the measurement proves that
the assertions pose significant performance cost.
Regards,
Peter
On Thu, Mar 5, 2020 at 4:12 PM sebb <se...@gmail.com> wrote:
> On Wed, 4 Mar 2020 at 14:20, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Le mer. 4 mars 2020 à 15:16, sebb <se...@gmail.com> a écrit :
> > >
> > > On Wed, 4 Mar 2020 at 14:09, Gary Gregory <ga...@gmail.com>
> wrote:
> > > >
> > > > IMO, until we are all on Java 14 and benefit from its more detailed
> NPE
> > > > message, we need to call Validate.notNull _with a message_ that says
> what
> > > > variable blew up.
> > >
> > > +1
> > >
> > > That is another good point.
> > >
> > > Unless one has access to the exact same version of the source, it can
> > > be very tricky to tell which variable has caused the NPE.
> > > The same applies to letting the JRE throw the NPE.
> >
> > Are you assuming that one should be able to fix the bug
> > without the stack trace?
>
> No, I'm saying that the stack trace is not much use without having
> access to the exact version of the source that was used to create the
> binary.
> An approximate line number may not be sufficient to identify the variable.
>
> > If so, I fail to see how having the name of a variable will
> > make it less tricky to locate the cause of the issue...
>
> See above.
>
> > Gilles
> >
> > >> [...]
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Peter Verhas
peter@verhas.com
t: +41791542095
skype: verhas
Re: [lang] NPE vs IAE
Posted by sebb <se...@gmail.com>.
On Thu, 5 Mar 2020 at 19:29, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le jeu. 5 mars 2020 à 16:12, sebb <se...@gmail.com> a écrit :
> >
> > On Wed, 4 Mar 2020 at 14:20, Gilles Sadowski <gi...@gmail.com> wrote:
> > >
> > > Le mer. 4 mars 2020 à 15:16, sebb <se...@gmail.com> a écrit :
> > > >
> > > > On Wed, 4 Mar 2020 at 14:09, Gary Gregory <ga...@gmail.com> wrote:
> > > > >
> > > > > IMO, until we are all on Java 14 and benefit from its more detailed NPE
> > > > > message, we need to call Validate.notNull _with a message_ that says what
> > > > > variable blew up.
> > > >
> > > > +1
> > > >
> > > > That is another good point.
> > > >
> > > > Unless one has access to the exact same version of the source, it can
> > > > be very tricky to tell which variable has caused the NPE.
> > > > The same applies to letting the JRE throw the NPE.
> > >
> > > Are you assuming that one should be able to fix the bug
> > > without the stack trace?
> >
> > No, I'm saying that the stack trace is not much use without having
> > access to the exact version of the source that was used to create the
> > binary.
> > An approximate line number may not be sufficient to identify the variable.
> >
> > > If so, I fail to see how having the name of a variable will
> > > make it less tricky to locate the cause of the issue...
> >
> > See above.
>
> I'm not trying to prove that less information is better.
>
> However without the exact source, having the exact
> name of the variable is similarly of not much use.
Huh?
The stack trace shows the name of the method in which the problem occurs.
If the exception shows the name of the variable, that uniquely
identifies it, even if the exact source is not known.
> IOW, with the exact source and in the case where
> the variable is used by the method itself, the stack
> shows exactly where the unexpected null occurred.
Of course, but the exact source may not be known.
> Moreover, if the null occurred because of a user error
> (e.g. missing configuration directive), the link with the
> variable name may not be obvious.
That is not relevant here.
> Gilles
>
> ---------------------------------------------------------------------
> 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: [lang] NPE vs IAE
Posted by Gilles Sadowski <gi...@gmail.com>.
Le jeu. 5 mars 2020 à 16:12, sebb <se...@gmail.com> a écrit :
>
> On Wed, 4 Mar 2020 at 14:20, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Le mer. 4 mars 2020 à 15:16, sebb <se...@gmail.com> a écrit :
> > >
> > > On Wed, 4 Mar 2020 at 14:09, Gary Gregory <ga...@gmail.com> wrote:
> > > >
> > > > IMO, until we are all on Java 14 and benefit from its more detailed NPE
> > > > message, we need to call Validate.notNull _with a message_ that says what
> > > > variable blew up.
> > >
> > > +1
> > >
> > > That is another good point.
> > >
> > > Unless one has access to the exact same version of the source, it can
> > > be very tricky to tell which variable has caused the NPE.
> > > The same applies to letting the JRE throw the NPE.
> >
> > Are you assuming that one should be able to fix the bug
> > without the stack trace?
>
> No, I'm saying that the stack trace is not much use without having
> access to the exact version of the source that was used to create the
> binary.
> An approximate line number may not be sufficient to identify the variable.
>
> > If so, I fail to see how having the name of a variable will
> > make it less tricky to locate the cause of the issue...
>
> See above.
I'm not trying to prove that less information is better.
However without the exact source, having the exact
name of the variable is similarly of not much use.
IOW, with the exact source and in the case where
the variable is used by the method itself, the stack
shows exactly where the unexpected null occurred.
Moreover, if the null occurred because of a user error
(e.g. missing configuration directive), the link with the
variable name may not be obvious.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] NPE vs IAE
Posted by sebb <se...@gmail.com>.
On Wed, 4 Mar 2020 at 14:20, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le mer. 4 mars 2020 à 15:16, sebb <se...@gmail.com> a écrit :
> >
> > On Wed, 4 Mar 2020 at 14:09, Gary Gregory <ga...@gmail.com> wrote:
> > >
> > > IMO, until we are all on Java 14 and benefit from its more detailed NPE
> > > message, we need to call Validate.notNull _with a message_ that says what
> > > variable blew up.
> >
> > +1
> >
> > That is another good point.
> >
> > Unless one has access to the exact same version of the source, it can
> > be very tricky to tell which variable has caused the NPE.
> > The same applies to letting the JRE throw the NPE.
>
> Are you assuming that one should be able to fix the bug
> without the stack trace?
No, I'm saying that the stack trace is not much use without having
access to the exact version of the source that was used to create the
binary.
An approximate line number may not be sufficient to identify the variable.
> If so, I fail to see how having the name of a variable will
> make it less tricky to locate the cause of the issue...
See above.
> Gilles
>
> >> [...]
>
> ---------------------------------------------------------------------
> 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: [lang] NPE vs IAE
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 4 mars 2020 à 15:16, sebb <se...@gmail.com> a écrit :
>
> On Wed, 4 Mar 2020 at 14:09, Gary Gregory <ga...@gmail.com> wrote:
> >
> > IMO, until we are all on Java 14 and benefit from its more detailed NPE
> > message, we need to call Validate.notNull _with a message_ that says what
> > variable blew up.
>
> +1
>
> That is another good point.
>
> Unless one has access to the exact same version of the source, it can
> be very tricky to tell which variable has caused the NPE.
> The same applies to letting the JRE throw the NPE.
Are you assuming that one should be able to fix the bug
without the stack trace?
If so, I fail to see how having the name of a variable will
make it less tricky to locate the cause of the issue...
Gilles
>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] NPE vs IAE
Posted by sebb <se...@gmail.com>.
On Wed, 4 Mar 2020 at 14:09, Gary Gregory <ga...@gmail.com> wrote:
>
> IMO, until we are all on Java 14 and benefit from its more detailed NPE
> message, we need to call Validate.notNull _with a message_ that says what
> variable blew up.
+1
That is another good point.
Unless one has access to the exact same version of the source, it can
be very tricky to tell which variable has caused the NPE.
The same applies to letting the JRE throw the NPE.
> Gary
>
> On Wed, Mar 4, 2020 at 9:01 AM Gilles Sadowski <gi...@gmail.com> wrote:
>
> > Le mer. 4 mars 2020 à 14:19, Gary Gregory <ga...@gmail.com> a
> > écrit :
> > >
> > > On Wed, Mar 4, 2020 at 7:58 AM sebb <se...@gmail.com> wrote:
> > >
> > > > On Sat, 29 Feb 2020 at 18:09, Gilles Sadowski <gi...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Le sam. 29 févr. 2020 à 18:39, Gary Gregory <ga...@gmail.com>
> > a
> > > > écrit :
> > > > > >
> > > > > > On Sat, Feb 22, 2020 at 5:25 PM Gary Gregory <
> > garydgregory@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > I would like to do the same in Lang as with Collections (see
> > below.)\
> > > > > > >
> > > > > > > We currently perform checks like:
> > > > > > >
> > > > > > > Validate.isTrue(foo != null, ...)
> > > > > > >
> > > > > > > Which should be IMO:
> > > > > > >
> > > > > > > Validate.notNull(foo, ...);
> > > > > > >
> > > > > > > The difference being that the former throws IAE and the later
> > NPE.
> > > > > > >
> > > > > > > As with [collections], my argument is the same, the JRE uses
> > > > > > > Objects.requireNonNull() to throw an NPE, so I'd like to keep
> > > > normalizing
> > > > > > > on that.
> > > > > > >
> > > > > >
> > > > > > Any thoughts? Should I proceed?
> > > > >
> > > >
> > > > +1
> > > >
> > > > > +1 for NPE on unexpected null.
> > > > > [But perhaps it is not necessary to double-check, as the JRE
> > > > > will do it anyway (and throw NPE).]
> > > >
> > >
> > > This is not about dropping the check, please re-read the thread,
> > > specifically:
> >
> > Please re-read my reply (3 and 4 lines above).
> > In line with what Sebb mentions; if the code is akin to
> > ---CUT---
> > void doSomethingWith(Object foo) {
> > Validate.notNull(foo, ...); // Provably unnecessary because...
> > System.out.println("foo=" + foo.toString()); // ... this will throw NPE.
> > // ...
> > }
> > ---CUT---
> > Then the check could be dropped, especially if it would throw
> > NPE instead of IAE.
> >
> > In fact, my impression is that, when we control the chain of calls
> > (e.g. when there is no external dependency), there is always a
> > point where NPE will be thrown (by the JRE) unless the reference
> > is never used; hence the check is not strictly necessary; it will only
> > abort the chain earlier, at the cost of doing many checks that are
> > not needed in the nominal case (where the reference is not null).
> >
> > Gilles
> >
> > >
> > > We currently perform checks like:
> > >
> > > Validate.isTrue(foo != null, ...)
> > >
> > > Which should be IMO:
> > >
> > > Validate.notNull(foo, ...);
> > >
> > > notNull calls the JRE's Objects.requireNonNull()
> > >
> > >
> > > > Depends on how and where the variable is used -- sometimes a null can
> > > > cause hard to track errors, not necessarily NPE, and the exception (or
> > > > possibly other failure) may be a long way from the initial method
> > > > call.
> > > >
> > > > It's almost always better to report the problem as early as possible.
> > > >
> > > > I think the existing checks should be kept.
> > > >
> > >
> > > Agreed, but I am talking but performing a better cleaner check by using
> > > Validate.notNull(foo, ...) instead of Validate.isTrue(foo != null, ...)
> > >
> > > Gary
> > >
> > >
> > > >
> > > > If it can be proved that the code would generate NPE immediately
> > > > anyway, it might be worth dropping the check.
> > > > However, code changes, so at least a comment should be left in its
> > > > place to note that the code is relying on Java to generate the NPE at
> > > > this point.
> > > >
> > >
> > > > > Gilles
> > > > >
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > ---------- Forwarded message ---------
> > > > > > > From: Gary Gregory <ga...@gmail.com>
> > > > > > > Date: Tue, Dec 10, 2019 at 9:59 AM
> > > > > > > Subject: Re: [collection] NPE vs IAE in
> > > > > > > org.apache.commons.collections4.CollectionUtils
> > > > > > > To: Commons Developers List <de...@commons.apache.org>, Bruno P.
> > > > Kinoshita <
> > > > > > > brunodepaulak@yahoo.com.br>
> > > > > > >
> > > > > > >
> > > > > > > FTR, using requireNonNull is also an 'Effective Java'
> > recommendation.
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > On Thu, Dec 5, 2019 at 4:54 PM Bruno P. Kinoshita
> > > > > > > <br...@yahoo.com.br.invalid> wrote:
> > > > > > >
> > > > > > >> +1 for NPE
> > > > > > >>
> > > > > > >> On Friday, 6 December 2019, 5:22:34 am NZDT, Gary Gregory <
> > > > > > >> garydgregory@gmail.com> wrote:
> > > > > > >>
> > > > > > >> Hi All:
> > > > > > >>
> > > > > > >> org.apache.commons.collections4.CollectionUtils contains a mix
> > of
> > > > checking
> > > > > > >> for null inputs by throwing NullPointerExceptions in some
> > methods
> > > > and
> > > > > > >> IllegalArgumentExceptions in others.
> > > > > > >>
> > > > > > >> I propose we standardized to NPE simply because the JRE provides
> > > > > > >> Objects.requireNonNull() just for this purpose.
> > > > > > >>
> > > > > > >> Gary
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > >
> >
> > ---------------------------------------------------------------------
> > 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: [lang] NPE vs IAE
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 4 mars 2020 à 15:16, Gilles Sadowski <gi...@gmail.com> a écrit :
>
> Le mer. 4 mars 2020 à 15:09, Gary Gregory <ga...@gmail.com> a écrit :
> >
> > IMO, until we are all on Java 14 and benefit from its more detailed NPE
> > message, we need to call Validate.notNull _with a message_ that says what
> > variable blew up.
>
> No, we don't *need* to (for the reason stated previously), but you
> may *want* to.
Anyways, see my initial reply; changing from throwing IAE to
throwing NPE is a first step towards ultimately dropping the
double-check while remaining functionally compatible.
Gilles
> > > [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] NPE vs IAE
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 4 mars 2020 à 15:09, Gary Gregory <ga...@gmail.com> a écrit :
>
> IMO, until we are all on Java 14 and benefit from its more detailed NPE
> message, we need to call Validate.notNull _with a message_ that says what
> variable blew up.
No, we don't *need* to (for the reason stated previously), but you
may *want* to.
Gilles
>
> Gary
>
> On Wed, Mar 4, 2020 at 9:01 AM Gilles Sadowski <gi...@gmail.com> wrote:
>
> > Le mer. 4 mars 2020 à 14:19, Gary Gregory <ga...@gmail.com> a
> > écrit :
> > >
> > > On Wed, Mar 4, 2020 at 7:58 AM sebb <se...@gmail.com> wrote:
> > >
> > > > On Sat, 29 Feb 2020 at 18:09, Gilles Sadowski <gi...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Le sam. 29 févr. 2020 à 18:39, Gary Gregory <ga...@gmail.com>
> > a
> > > > écrit :
> > > > > >
> > > > > > On Sat, Feb 22, 2020 at 5:25 PM Gary Gregory <
> > garydgregory@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > I would like to do the same in Lang as with Collections (see
> > below.)\
> > > > > > >
> > > > > > > We currently perform checks like:
> > > > > > >
> > > > > > > Validate.isTrue(foo != null, ...)
> > > > > > >
> > > > > > > Which should be IMO:
> > > > > > >
> > > > > > > Validate.notNull(foo, ...);
> > > > > > >
> > > > > > > The difference being that the former throws IAE and the later
> > NPE.
> > > > > > >
> > > > > > > As with [collections], my argument is the same, the JRE uses
> > > > > > > Objects.requireNonNull() to throw an NPE, so I'd like to keep
> > > > normalizing
> > > > > > > on that.
> > > > > > >
> > > > > >
> > > > > > Any thoughts? Should I proceed?
> > > > >
> > > >
> > > > +1
> > > >
> > > > > +1 for NPE on unexpected null.
> > > > > [But perhaps it is not necessary to double-check, as the JRE
> > > > > will do it anyway (and throw NPE).]
> > > >
> > >
> > > This is not about dropping the check, please re-read the thread,
> > > specifically:
> >
> > Please re-read my reply (3 and 4 lines above).
> > In line with what Sebb mentions; if the code is akin to
> > ---CUT---
> > void doSomethingWith(Object foo) {
> > Validate.notNull(foo, ...); // Provably unnecessary because...
> > System.out.println("foo=" + foo.toString()); // ... this will throw NPE.
> > // ...
> > }
> > ---CUT---
> > Then the check could be dropped, especially if it would throw
> > NPE instead of IAE.
> >
> > In fact, my impression is that, when we control the chain of calls
> > (e.g. when there is no external dependency), there is always a
> > point where NPE will be thrown (by the JRE) unless the reference
> > is never used; hence the check is not strictly necessary; it will only
> > abort the chain earlier, at the cost of doing many checks that are
> > not needed in the nominal case (where the reference is not null).
> >
> > Gilles
> >
> > >
> > > We currently perform checks like:
> > >
> > > Validate.isTrue(foo != null, ...)
> > >
> > > Which should be IMO:
> > >
> > > Validate.notNull(foo, ...);
> > >
> > > notNull calls the JRE's Objects.requireNonNull()
> > >
> > >
> > > > Depends on how and where the variable is used -- sometimes a null can
> > > > cause hard to track errors, not necessarily NPE, and the exception (or
> > > > possibly other failure) may be a long way from the initial method
> > > > call.
> > > >
> > > > It's almost always better to report the problem as early as possible.
> > > >
> > > > I think the existing checks should be kept.
> > > >
> > >
> > > Agreed, but I am talking but performing a better cleaner check by using
> > > Validate.notNull(foo, ...) instead of Validate.isTrue(foo != null, ...)
> > >
> > > Gary
> > >
> > >
> > > >
> > > > If it can be proved that the code would generate NPE immediately
> > > > anyway, it might be worth dropping the check.
> > > > However, code changes, so at least a comment should be left in its
> > > > place to note that the code is relying on Java to generate the NPE at
> > > > this point.
> > > >
> > >
> > > > > Gilles
> > > > >
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > ---------- Forwarded message ---------
> > > > > > > From: Gary Gregory <ga...@gmail.com>
> > > > > > > Date: Tue, Dec 10, 2019 at 9:59 AM
> > > > > > > Subject: Re: [collection] NPE vs IAE in
> > > > > > > org.apache.commons.collections4.CollectionUtils
> > > > > > > To: Commons Developers List <de...@commons.apache.org>, Bruno P.
> > > > Kinoshita <
> > > > > > > brunodepaulak@yahoo.com.br>
> > > > > > >
> > > > > > >
> > > > > > > FTR, using requireNonNull is also an 'Effective Java'
> > recommendation.
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > On Thu, Dec 5, 2019 at 4:54 PM Bruno P. Kinoshita
> > > > > > > <br...@yahoo.com.br.invalid> wrote:
> > > > > > >
> > > > > > >> +1 for NPE
> > > > > > >>
> > > > > > >> On Friday, 6 December 2019, 5:22:34 am NZDT, Gary Gregory <
> > > > > > >> garydgregory@gmail.com> wrote:
> > > > > > >>
> > > > > > >> Hi All:
> > > > > > >>
> > > > > > >> org.apache.commons.collections4.CollectionUtils contains a mix
> > of
> > > > checking
> > > > > > >> for null inputs by throwing NullPointerExceptions in some
> > methods
> > > > and
> > > > > > >> IllegalArgumentExceptions in others.
> > > > > > >>
> > > > > > >> I propose we standardized to NPE simply because the JRE provides
> > > > > > >> Objects.requireNonNull() just for this purpose.
> > > > > > >>
> > > > > > >> Gary
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > >
> >
> > ---------------------------------------------------------------------
> > 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: [lang] NPE vs IAE
Posted by Gary Gregory <ga...@gmail.com>.
IMO, until we are all on Java 14 and benefit from its more detailed NPE
message, we need to call Validate.notNull _with a message_ that says what
variable blew up.
Gary
On Wed, Mar 4, 2020 at 9:01 AM Gilles Sadowski <gi...@gmail.com> wrote:
> Le mer. 4 mars 2020 à 14:19, Gary Gregory <ga...@gmail.com> a
> écrit :
> >
> > On Wed, Mar 4, 2020 at 7:58 AM sebb <se...@gmail.com> wrote:
> >
> > > On Sat, 29 Feb 2020 at 18:09, Gilles Sadowski <gi...@gmail.com>
> > > wrote:
> > > >
> > > > Le sam. 29 févr. 2020 à 18:39, Gary Gregory <ga...@gmail.com>
> a
> > > écrit :
> > > > >
> > > > > On Sat, Feb 22, 2020 at 5:25 PM Gary Gregory <
> garydgregory@gmail.com>
> > > wrote:
> > > > >
> > > > > > I would like to do the same in Lang as with Collections (see
> below.)\
> > > > > >
> > > > > > We currently perform checks like:
> > > > > >
> > > > > > Validate.isTrue(foo != null, ...)
> > > > > >
> > > > > > Which should be IMO:
> > > > > >
> > > > > > Validate.notNull(foo, ...);
> > > > > >
> > > > > > The difference being that the former throws IAE and the later
> NPE.
> > > > > >
> > > > > > As with [collections], my argument is the same, the JRE uses
> > > > > > Objects.requireNonNull() to throw an NPE, so I'd like to keep
> > > normalizing
> > > > > > on that.
> > > > > >
> > > > >
> > > > > Any thoughts? Should I proceed?
> > > >
> > >
> > > +1
> > >
> > > > +1 for NPE on unexpected null.
> > > > [But perhaps it is not necessary to double-check, as the JRE
> > > > will do it anyway (and throw NPE).]
> > >
> >
> > This is not about dropping the check, please re-read the thread,
> > specifically:
>
> Please re-read my reply (3 and 4 lines above).
> In line with what Sebb mentions; if the code is akin to
> ---CUT---
> void doSomethingWith(Object foo) {
> Validate.notNull(foo, ...); // Provably unnecessary because...
> System.out.println("foo=" + foo.toString()); // ... this will throw NPE.
> // ...
> }
> ---CUT---
> Then the check could be dropped, especially if it would throw
> NPE instead of IAE.
>
> In fact, my impression is that, when we control the chain of calls
> (e.g. when there is no external dependency), there is always a
> point where NPE will be thrown (by the JRE) unless the reference
> is never used; hence the check is not strictly necessary; it will only
> abort the chain earlier, at the cost of doing many checks that are
> not needed in the nominal case (where the reference is not null).
>
> Gilles
>
> >
> > We currently perform checks like:
> >
> > Validate.isTrue(foo != null, ...)
> >
> > Which should be IMO:
> >
> > Validate.notNull(foo, ...);
> >
> > notNull calls the JRE's Objects.requireNonNull()
> >
> >
> > > Depends on how and where the variable is used -- sometimes a null can
> > > cause hard to track errors, not necessarily NPE, and the exception (or
> > > possibly other failure) may be a long way from the initial method
> > > call.
> > >
> > > It's almost always better to report the problem as early as possible.
> > >
> > > I think the existing checks should be kept.
> > >
> >
> > Agreed, but I am talking but performing a better cleaner check by using
> > Validate.notNull(foo, ...) instead of Validate.isTrue(foo != null, ...)
> >
> > Gary
> >
> >
> > >
> > > If it can be proved that the code would generate NPE immediately
> > > anyway, it might be worth dropping the check.
> > > However, code changes, so at least a comment should be left in its
> > > place to note that the code is relying on Java to generate the NPE at
> > > this point.
> > >
> >
> > > > Gilles
> > > >
> > > > >
> > > > > Gary
> > > > >
> > > > >
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > ---------- Forwarded message ---------
> > > > > > From: Gary Gregory <ga...@gmail.com>
> > > > > > Date: Tue, Dec 10, 2019 at 9:59 AM
> > > > > > Subject: Re: [collection] NPE vs IAE in
> > > > > > org.apache.commons.collections4.CollectionUtils
> > > > > > To: Commons Developers List <de...@commons.apache.org>, Bruno P.
> > > Kinoshita <
> > > > > > brunodepaulak@yahoo.com.br>
> > > > > >
> > > > > >
> > > > > > FTR, using requireNonNull is also an 'Effective Java'
> recommendation.
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Thu, Dec 5, 2019 at 4:54 PM Bruno P. Kinoshita
> > > > > > <br...@yahoo.com.br.invalid> wrote:
> > > > > >
> > > > > >> +1 for NPE
> > > > > >>
> > > > > >> On Friday, 6 December 2019, 5:22:34 am NZDT, Gary Gregory <
> > > > > >> garydgregory@gmail.com> wrote:
> > > > > >>
> > > > > >> Hi All:
> > > > > >>
> > > > > >> org.apache.commons.collections4.CollectionUtils contains a mix
> of
> > > checking
> > > > > >> for null inputs by throwing NullPointerExceptions in some
> methods
> > > and
> > > > > >> IllegalArgumentExceptions in others.
> > > > > >>
> > > > > >> I propose we standardized to NPE simply because the JRE provides
> > > > > >> Objects.requireNonNull() just for this purpose.
> > > > > >>
> > > > > >> Gary
> > > > > >>
> > > > > >
> > > > > >
> > > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [lang] NPE vs IAE
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 4 mars 2020 à 14:19, Gary Gregory <ga...@gmail.com> a écrit :
>
> On Wed, Mar 4, 2020 at 7:58 AM sebb <se...@gmail.com> wrote:
>
> > On Sat, 29 Feb 2020 at 18:09, Gilles Sadowski <gi...@gmail.com>
> > wrote:
> > >
> > > Le sam. 29 févr. 2020 à 18:39, Gary Gregory <ga...@gmail.com> a
> > écrit :
> > > >
> > > > On Sat, Feb 22, 2020 at 5:25 PM Gary Gregory <ga...@gmail.com>
> > wrote:
> > > >
> > > > > I would like to do the same in Lang as with Collections (see below.)\
> > > > >
> > > > > We currently perform checks like:
> > > > >
> > > > > Validate.isTrue(foo != null, ...)
> > > > >
> > > > > Which should be IMO:
> > > > >
> > > > > Validate.notNull(foo, ...);
> > > > >
> > > > > The difference being that the former throws IAE and the later NPE.
> > > > >
> > > > > As with [collections], my argument is the same, the JRE uses
> > > > > Objects.requireNonNull() to throw an NPE, so I'd like to keep
> > normalizing
> > > > > on that.
> > > > >
> > > >
> > > > Any thoughts? Should I proceed?
> > >
> >
> > +1
> >
> > > +1 for NPE on unexpected null.
> > > [But perhaps it is not necessary to double-check, as the JRE
> > > will do it anyway (and throw NPE).]
> >
>
> This is not about dropping the check, please re-read the thread,
> specifically:
Please re-read my reply (3 and 4 lines above).
In line with what Sebb mentions; if the code is akin to
---CUT---
void doSomethingWith(Object foo) {
Validate.notNull(foo, ...); // Provably unnecessary because...
System.out.println("foo=" + foo.toString()); // ... this will throw NPE.
// ...
}
---CUT---
Then the check could be dropped, especially if it would throw
NPE instead of IAE.
In fact, my impression is that, when we control the chain of calls
(e.g. when there is no external dependency), there is always a
point where NPE will be thrown (by the JRE) unless the reference
is never used; hence the check is not strictly necessary; it will only
abort the chain earlier, at the cost of doing many checks that are
not needed in the nominal case (where the reference is not null).
Gilles
>
> We currently perform checks like:
>
> Validate.isTrue(foo != null, ...)
>
> Which should be IMO:
>
> Validate.notNull(foo, ...);
>
> notNull calls the JRE's Objects.requireNonNull()
>
>
> > Depends on how and where the variable is used -- sometimes a null can
> > cause hard to track errors, not necessarily NPE, and the exception (or
> > possibly other failure) may be a long way from the initial method
> > call.
> >
> > It's almost always better to report the problem as early as possible.
> >
> > I think the existing checks should be kept.
> >
>
> Agreed, but I am talking but performing a better cleaner check by using
> Validate.notNull(foo, ...) instead of Validate.isTrue(foo != null, ...)
>
> Gary
>
>
> >
> > If it can be proved that the code would generate NPE immediately
> > anyway, it might be worth dropping the check.
> > However, code changes, so at least a comment should be left in its
> > place to note that the code is relying on Java to generate the NPE at
> > this point.
> >
>
> > > Gilles
> > >
> > > >
> > > > Gary
> > > >
> > > >
> > > > >
> > > > > Gary
> > > > >
> > > > > ---------- Forwarded message ---------
> > > > > From: Gary Gregory <ga...@gmail.com>
> > > > > Date: Tue, Dec 10, 2019 at 9:59 AM
> > > > > Subject: Re: [collection] NPE vs IAE in
> > > > > org.apache.commons.collections4.CollectionUtils
> > > > > To: Commons Developers List <de...@commons.apache.org>, Bruno P.
> > Kinoshita <
> > > > > brunodepaulak@yahoo.com.br>
> > > > >
> > > > >
> > > > > FTR, using requireNonNull is also an 'Effective Java' recommendation.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Thu, Dec 5, 2019 at 4:54 PM Bruno P. Kinoshita
> > > > > <br...@yahoo.com.br.invalid> wrote:
> > > > >
> > > > >> +1 for NPE
> > > > >>
> > > > >> On Friday, 6 December 2019, 5:22:34 am NZDT, Gary Gregory <
> > > > >> garydgregory@gmail.com> wrote:
> > > > >>
> > > > >> Hi All:
> > > > >>
> > > > >> org.apache.commons.collections4.CollectionUtils contains a mix of
> > checking
> > > > >> for null inputs by throwing NullPointerExceptions in some methods
> > and
> > > > >> IllegalArgumentExceptions in others.
> > > > >>
> > > > >> I propose we standardized to NPE simply because the JRE provides
> > > > >> Objects.requireNonNull() just for this purpose.
> > > > >>
> > > > >> Gary
> > > > >>
> > > > >
> > > > >
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] NPE vs IAE
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Mar 4, 2020 at 7:58 AM sebb <se...@gmail.com> wrote:
> On Sat, 29 Feb 2020 at 18:09, Gilles Sadowski <gi...@gmail.com>
> wrote:
> >
> > Le sam. 29 févr. 2020 à 18:39, Gary Gregory <ga...@gmail.com> a
> écrit :
> > >
> > > On Sat, Feb 22, 2020 at 5:25 PM Gary Gregory <ga...@gmail.com>
> wrote:
> > >
> > > > I would like to do the same in Lang as with Collections (see below.)\
> > > >
> > > > We currently perform checks like:
> > > >
> > > > Validate.isTrue(foo != null, ...)
> > > >
> > > > Which should be IMO:
> > > >
> > > > Validate.notNull(foo, ...);
> > > >
> > > > The difference being that the former throws IAE and the later NPE.
> > > >
> > > > As with [collections], my argument is the same, the JRE uses
> > > > Objects.requireNonNull() to throw an NPE, so I'd like to keep
> normalizing
> > > > on that.
> > > >
> > >
> > > Any thoughts? Should I proceed?
> >
>
> +1
>
> > +1 for NPE on unexpected null.
> > [But perhaps it is not necessary to double-check, as the JRE
> > will do it anyway (and throw NPE).]
>
This is not about dropping the check, please re-read the thread,
specifically:
We currently perform checks like:
Validate.isTrue(foo != null, ...)
Which should be IMO:
Validate.notNull(foo, ...);
notNull calls the JRE's Objects.requireNonNull()
> Depends on how and where the variable is used -- sometimes a null can
> cause hard to track errors, not necessarily NPE, and the exception (or
> possibly other failure) may be a long way from the initial method
> call.
>
> It's almost always better to report the problem as early as possible.
>
> I think the existing checks should be kept.
>
Agreed, but I am talking but performing a better cleaner check by using
Validate.notNull(foo, ...) instead of Validate.isTrue(foo != null, ...)
Gary
>
> If it can be proved that the code would generate NPE immediately
> anyway, it might be worth dropping the check.
> However, code changes, so at least a comment should be left in its
> place to note that the code is relying on Java to generate the NPE at
> this point.
>
> > Gilles
> >
> > >
> > > Gary
> > >
> > >
> > > >
> > > > Gary
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: Gary Gregory <ga...@gmail.com>
> > > > Date: Tue, Dec 10, 2019 at 9:59 AM
> > > > Subject: Re: [collection] NPE vs IAE in
> > > > org.apache.commons.collections4.CollectionUtils
> > > > To: Commons Developers List <de...@commons.apache.org>, Bruno P.
> Kinoshita <
> > > > brunodepaulak@yahoo.com.br>
> > > >
> > > >
> > > > FTR, using requireNonNull is also an 'Effective Java' recommendation.
> > > >
> > > > Gary
> > > >
> > > > On Thu, Dec 5, 2019 at 4:54 PM Bruno P. Kinoshita
> > > > <br...@yahoo.com.br.invalid> wrote:
> > > >
> > > >> +1 for NPE
> > > >>
> > > >> On Friday, 6 December 2019, 5:22:34 am NZDT, Gary Gregory <
> > > >> garydgregory@gmail.com> wrote:
> > > >>
> > > >> Hi All:
> > > >>
> > > >> org.apache.commons.collections4.CollectionUtils contains a mix of
> checking
> > > >> for null inputs by throwing NullPointerExceptions in some methods
> and
> > > >> IllegalArgumentExceptions in others.
> > > >>
> > > >> I propose we standardized to NPE simply because the JRE provides
> > > >> Objects.requireNonNull() just for this purpose.
> > > >>
> > > >> Gary
> > > >>
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > 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: [lang] NPE vs IAE
Posted by sebb <se...@gmail.com>.
On Sat, 29 Feb 2020 at 18:09, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le sam. 29 févr. 2020 à 18:39, Gary Gregory <ga...@gmail.com> a écrit :
> >
> > On Sat, Feb 22, 2020 at 5:25 PM Gary Gregory <ga...@gmail.com> wrote:
> >
> > > I would like to do the same in Lang as with Collections (see below.)\
> > >
> > > We currently perform checks like:
> > >
> > > Validate.isTrue(foo != null, ...)
> > >
> > > Which should be IMO:
> > >
> > > Validate.notNull(foo, ...);
> > >
> > > The difference being that the former throws IAE and the later NPE.
> > >
> > > As with [collections], my argument is the same, the JRE uses
> > > Objects.requireNonNull() to throw an NPE, so I'd like to keep normalizing
> > > on that.
> > >
> >
> > Any thoughts? Should I proceed?
>
+1
> +1 for NPE on unexpected null.
> [But perhaps it is not necessary to double-check, as the JRE
> will do it anyway (and throw NPE).]
Depends on how and where the variable is used -- sometimes a null can
cause hard to track errors, not necessarily NPE, and the exception (or
possibly other failure) may be a long way from the initial method
call.
It's almost always better to report the problem as early as possible.
I think the existing checks should be kept.
If it can be proved that the code would generate NPE immediately
anyway, it might be worth dropping the check.
However, code changes, so at least a comment should be left in its
place to note that the code is relying on Java to generate the NPE at
this point.
> Gilles
>
> >
> > Gary
> >
> >
> > >
> > > Gary
> > >
> > > ---------- Forwarded message ---------
> > > From: Gary Gregory <ga...@gmail.com>
> > > Date: Tue, Dec 10, 2019 at 9:59 AM
> > > Subject: Re: [collection] NPE vs IAE in
> > > org.apache.commons.collections4.CollectionUtils
> > > To: Commons Developers List <de...@commons.apache.org>, Bruno P. Kinoshita <
> > > brunodepaulak@yahoo.com.br>
> > >
> > >
> > > FTR, using requireNonNull is also an 'Effective Java' recommendation.
> > >
> > > Gary
> > >
> > > On Thu, Dec 5, 2019 at 4:54 PM Bruno P. Kinoshita
> > > <br...@yahoo.com.br.invalid> wrote:
> > >
> > >> +1 for NPE
> > >>
> > >> On Friday, 6 December 2019, 5:22:34 am NZDT, Gary Gregory <
> > >> garydgregory@gmail.com> wrote:
> > >>
> > >> Hi All:
> > >>
> > >> org.apache.commons.collections4.CollectionUtils contains a mix of checking
> > >> for null inputs by throwing NullPointerExceptions in some methods and
> > >> IllegalArgumentExceptions in others.
> > >>
> > >> I propose we standardized to NPE simply because the JRE provides
> > >> Objects.requireNonNull() just for this purpose.
> > >>
> > >> Gary
> > >>
> > >
> > >
>
> ---------------------------------------------------------------------
> 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: [lang] NPE vs IAE
Posted by Gilles Sadowski <gi...@gmail.com>.
Le sam. 29 févr. 2020 à 18:39, Gary Gregory <ga...@gmail.com> a écrit :
>
> On Sat, Feb 22, 2020 at 5:25 PM Gary Gregory <ga...@gmail.com> wrote:
>
> > I would like to do the same in Lang as with Collections (see below.)\
> >
> > We currently perform checks like:
> >
> > Validate.isTrue(foo != null, ...)
> >
> > Which should be IMO:
> >
> > Validate.notNull(foo, ...);
> >
> > The difference being that the former throws IAE and the later NPE.
> >
> > As with [collections], my argument is the same, the JRE uses
> > Objects.requireNonNull() to throw an NPE, so I'd like to keep normalizing
> > on that.
> >
>
> Any thoughts? Should I proceed?
+1 for NPE on unexpected null.
[But perhaps it is not necessary to double-check, as the JRE
will do it anyway (and throw NPE).]
Gilles
>
> Gary
>
>
> >
> > Gary
> >
> > ---------- Forwarded message ---------
> > From: Gary Gregory <ga...@gmail.com>
> > Date: Tue, Dec 10, 2019 at 9:59 AM
> > Subject: Re: [collection] NPE vs IAE in
> > org.apache.commons.collections4.CollectionUtils
> > To: Commons Developers List <de...@commons.apache.org>, Bruno P. Kinoshita <
> > brunodepaulak@yahoo.com.br>
> >
> >
> > FTR, using requireNonNull is also an 'Effective Java' recommendation.
> >
> > Gary
> >
> > On Thu, Dec 5, 2019 at 4:54 PM Bruno P. Kinoshita
> > <br...@yahoo.com.br.invalid> wrote:
> >
> >> +1 for NPE
> >>
> >> On Friday, 6 December 2019, 5:22:34 am NZDT, Gary Gregory <
> >> garydgregory@gmail.com> wrote:
> >>
> >> Hi All:
> >>
> >> org.apache.commons.collections4.CollectionUtils contains a mix of checking
> >> for null inputs by throwing NullPointerExceptions in some methods and
> >> IllegalArgumentExceptions in others.
> >>
> >> I propose we standardized to NPE simply because the JRE provides
> >> Objects.requireNonNull() just for this purpose.
> >>
> >> Gary
> >>
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] NPE vs IAE
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Feb 22, 2020 at 5:25 PM Gary Gregory <ga...@gmail.com> wrote:
> I would like to do the same in Lang as with Collections (see below.)\
>
> We currently perform checks like:
>
> Validate.isTrue(foo != null, ...)
>
> Which should be IMO:
>
> Validate.notNull(foo, ...);
>
> The difference being that the former throws IAE and the later NPE.
>
> As with [collections], my argument is the same, the JRE uses
> Objects.requireNonNull() to throw an NPE, so I'd like to keep normalizing
> on that.
>
Any thoughts? Should I proceed?
Gary
>
> Gary
>
> ---------- Forwarded message ---------
> From: Gary Gregory <ga...@gmail.com>
> Date: Tue, Dec 10, 2019 at 9:59 AM
> Subject: Re: [collection] NPE vs IAE in
> org.apache.commons.collections4.CollectionUtils
> To: Commons Developers List <de...@commons.apache.org>, Bruno P. Kinoshita <
> brunodepaulak@yahoo.com.br>
>
>
> FTR, using requireNonNull is also an 'Effective Java' recommendation.
>
> Gary
>
> On Thu, Dec 5, 2019 at 4:54 PM Bruno P. Kinoshita
> <br...@yahoo.com.br.invalid> wrote:
>
>> +1 for NPE
>>
>> On Friday, 6 December 2019, 5:22:34 am NZDT, Gary Gregory <
>> garydgregory@gmail.com> wrote:
>>
>> Hi All:
>>
>> org.apache.commons.collections4.CollectionUtils contains a mix of checking
>> for null inputs by throwing NullPointerExceptions in some methods and
>> IllegalArgumentExceptions in others.
>>
>> I propose we standardized to NPE simply because the JRE provides
>> Objects.requireNonNull() just for this purpose.
>>
>> Gary
>>
>
>