Hi, 2012/9/13 Gilles Sadowski <gil...@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-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
