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 Thu, 13 Sep 2012 19:15:24 GMT
Hi,

2012/9/13 Gilles Sadowski <gilles@harfang.homelinux.org>:
> 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.

S├ębastien

> 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)
> http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Preconditions.html#checkNotNull(T)
>
>
>
> 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


Mime
View raw message