commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [Math] About "NullArgumentException"
Date Fri, 14 Sep 2012 06:46:24 GMT
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 user that
>>     no NPE will ever propagate through the CM layer. [Breaking that promise
>>     is a CM bug.]
>>  2. CM to never check for null? Then we delete class "NullArgumentException".
>>     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 raising
>>     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 the
>>     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 (marginally)
>>     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├ębastien
>>
>> Your alternative (sometimes check, sometimes not) is not fully consistent:
>>  * for the user: "In case of null reference, will I get a MathRuntimeException
>>    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 that
>> would fail with all three alternatives which I suggested. If not, then
>> it seems obvious that your alternative presents two defects that don't exist
>> 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 problem
>>>> 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 passed
an
>>>> invalid (null) argument.
>>>>
>>>> Finally, the case for "null" is also slightly peculiar (given the above)
>>>> 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 just
>>>> fail in the predictable way: NPE).[1]
>>>>
>>>>
>>>> Gilles
>>>>
>>>> [1] Unlike in C, where an unitialized pointer would not necessarily crash
>>>>     the program, but _could_ make it behave erratically (including produce
>>>>     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


Mime
View raw message