commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <>
Subject Re: [Math] About "NullArgumentException"
Date Thu, 13 Sep 2012 19:15:24 GMT

2012/9/13 Gilles Sadowski <>:
> On Thu, Sep 13, 2012 at 01:10:41AM +0200, Gilles Sadowski wrote:
>> Hello.
>> [For those who don't wish to read the whole post, please at least go towards
>> the end and indicate your preferred option. Thanks.]
>> [... long post skipped ...]
>> 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.
> My preference would be alternative 2 but I'd be happy with alternative 3 too
> (as a compromise to allow checks for people who need more time to get rid
> of the habit :-).
I would also favor option #2. I can live with #3.


> With those additional arguments, for good measure:
> (a)
> ---
> Thrown when an application attempts to use null in a case where an object is
> required. These include:
>     Calling the instance method of a null object.
>     Accessing or modifying the field of a null object.
>     Taking the length of null as if it were an array.
>     Accessing or modifying the slots of null as if it were an array.
>     Throwing null as if it were a Throwable value.
> Applications should throw instances of this class to indicate other illegal
> uses of the null object.
> ---
> [This is the Javadoc for NPE. Please note the last sentence.]
> (b)
> "null" is not a representation of an application-domain concept, it is a low
> low low level literal (the unique element of the null-type) and exists solely
> to be the value of unitialized pointers (not even "reference"). It is only
> perfectly right that attempts to use "null" are set apart from other bugs
> (that acquire meaning only wrt to higher level preconditions).
> (c)
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message