Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of
 SRS0=wKP9=HN=m4x.org=sebastien.brisard@bounces.m4x.org designates
 129.104.30.34 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50526192.7060003@gmail.com>
References: 
 <CAGRH7HpMneOZQc1te3p5GmKpPPfcRmKYi5YCFWS5Rf73hsmB6w@mail.gmail.com>
	<504E4E10.5000404@gmail.com>
	<CAGRH7Hr2uMx4iHPU2Gbr96igXAjy4iBxEr64e0s8iDCW11H7Sg@mail.gmail.com>
	<20120912110727.GC20488@dusk.harfang.homelinux.org>
	<CAGRH7Hoo6pnfoS6D6Jc8jBC-mmVEK-1bXfCNtsYxDDaMFt+pYg@mail.gmail.com>
	<20120912114610.GF20488@dusk.harfang.homelinux.org>
	<CAGRH7HrmycCfh73C1o1n8=WfiamTp5SXxib4gE31om-H93=B=Q@mail.gmail.com>
	<50509A40.6050908@gmail.com>
	<20120912155232.GI20488@dusk.harfang.homelinux.org>
	<5050B912.7040402@gmail.com>
	<20120912231041.GU24856@dusk.harfang.homelinux.org>
	<50526192.7060003@gmail.com>
Date: Fri, 14 Sep 2012 08:46:24 +0200
Message-ID: 
 <CAGRH7Hq-B776UcdHxDyQavg3HFX3=Y5tL3AqEjoNvzo-Uw2FFQ@mail.gmail.com>
Subject: Re: [Math] About "NullArgumentException"
From: =?ISO-8859-1?Q?S=E9bastien_Brisard?= <sebastien.brisard@m4x.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Phil

>>
>> Back to square one, with 3 fully consistent alternatives:
>>  1. CM to always check for null? Then "NullArgumentException" inheriting=
 from
>>     "MathIllegalArgumentException" is fine because we promise to the use=
r that
>>     no NPE will ever propagate through the CM layer. [Breaking that prom=
ise
>>     is a CM bug.]
>>  2. CM to never check for null? Then we delete class "NullArgumentExcept=
ion".
>>     Users are warned by the general policy: "Do not pass null unless it =
is
>>     explicitly documented to be allowed." A bug will lead to the JVM rai=
sing
>>     a NPE.
>>  3. CM to sometimes check for null? Then "NullArgumentException" should
>>     inherit from "NullPointerException" because the user will sometimes =
see
>>     "NullArgumentException" (when CM checks) and sometimes NPE (when CM =
does
>>     not check) and both should thus belong to the same hierarchy (from t=
he
>>     user's point-of-view, there is no reason to handle them in different
>>     ways since it's the exact same bug).
>>     For the user, the consequence will be similar to alternative 2, with
>>     sometimes more information about the failure and sometimes (marginal=
ly)
>>     earlier detection.
>
> As stated above, my preference is
>
> 4.  CM APIs *may* disallow nulls explicitly.  When that is done, the
> implementations *should* check parameters (as they *should* check
> all other stated preconditions) and when preconditions are violated,
> a MathIllegalArgumentException is thrown.  I don't care whether or
> not we keep NAE.  If we drop it, we should make sure whatever
> exception messages we used to use to indicate illegal null arguments
> are still there.
>
> Phil
>
I like this option better than 3. So, I'll change my "vote" to option
#2, and possibly option #4 as we will never agree on option #2.

Best regards,
S=E9bastien
>>
>> Your alternative (sometimes check, sometimes not) is not fully consisten=
t:
>>  * for the user: "In case of null reference, will I get a MathRuntimeExc=
eption
>>    or a NPE?"
>>  * for the CM developer: "In which cases do I need to check for null?"
>>
>> Of course, I would reconsider if you could provide an actual example tha=
t
>> would fail with all three alternatives which I suggested. If not, then
>> it seems obvious that your alternative presents two defects that don't e=
xist
>> in any of those three.
>>
>>
>> Gilles
>>
>>>>> [...] what is different about null arguments at the point of
>>>>> method activation in an API that explicitly disallows them.
>>>> The difference is that there is no need to tell the user what the prob=
lem
>>>> is because the raised exception says it all: "You tried to use a null
>>>> reference." [As said above, the only issue is _when_ the exception is
>>>> triggered.]
>>>>
>>>> The policy mandates what is globally valid, e.g.:
>>>>   "If not specified otherwise, "null" is not allowed as an argument."
>>>> Then, a user cannot complain about a NPE being propagated when he pass=
ed an
>>>> invalid (null) argument.
>>>>
>>>> Finally, the case for "null" is also slightly peculiar (given the abov=
e)
>>>> that it should not simply be bundled with the rationale "Fail early": =
Indeed
>>>> "null" references always fail early (i.e. as soon as they are used).
>>>> Deferring the check until it is done by the JVM will never entails the=
 code
>>>> to produce a wrong result _because_ of that null reference (it will ju=
st
>>>> fail in the predictable way: NPE).[1]
>>>>
>>>>
>>>> Gilles
>>>>
>>>> [1] Unlike in C, where an unitialized pointer would not necessarily cr=
ash
>>>>     the program, but _could_ make it behave erratically (including pro=
duce
>>>>     wrong results in a stealth way).
>>>>
>> ---------------------------------------------------------------------
>> 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
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org