--------------------------------------------------
From: "Gilles Sadowski" <gil...@harfang.homelinux.org>
Sent: Wednesday, August 04, 2010 2:27 PM
To: <dev@commons.apache.org>
Subject: Re: [Math] Usage of "NullPointerException"
> A simpler policy would be to not check for "null" and let the JVM do
> it. As
> the JVM will do it anyway, it's a redundant check when the reference is
> not
> null, i.e. most of time (in legitimate usage).
This simpler policy seems fine to me.
However, it is an important change from previous behaviour.
In practice it is not that important: there are currently only 29
occurrences of messages referring to "null"; among those only 6 raise a
NullPointerException (the others throw an IllegalArgumentException).
> When the usage is wrong, the error is obvious and always the same
> ("null
> reference") and the "NullPointerException" fully identify the problem.
> I
> don't see why we should have a localized version of it. Yes, again,
> there
> are detailed messages saying:
> "the covariance matrix cannot be null"
> "the function cannot be null"
> "the denominator cannot be null"
> etc.
> But since any reference can potentially be "null", do you really intend
> to
> have a specific meesage for every object?
For these very low level errors, I would be happy with the single
message from JVM.
I would be happy with a single message from the JVM. Especially since we
are now inconsistent about when we use the localized version vs. the JVM
version of NPE.
So, shall I remove all checks for "null" (and those items in
"LocalizedFormats" that are used for reporting it)?
Should I open a JIRA issue?
It looks like we'll need a JIRA for this. Since we have places that
document that it throws IAE on a null parameter, that would be an
incompatible change for 2.2. So they would have to wait for 3.0.
If you want to change the places where we throw a localized NPE, that would
be fine for 2.2 IMHO (my quick spot check only shows BigFraction). Knock
yourself out.
Gilles
---------------------------------------------------------------------
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
