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 Mon, 17 Sep 2012 10:31:56 GMT
Hi Gilles,

2012/9/17 Luc Maisonobe <>:
> Le 17/09/2012 11:50, Gilles Sadowski a écrit :
>> On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote:
>>> OK, I give up.  Lets do option 2.  Just warn users in the User Guide
>>> somewhere that our APIs are in general not null-safe and unless the
>>> javadoc explicitly allows nulls, they can expect NPE when passing nulls.
>> Thanks, Phil; we are making progress, and I hope that you'll be convinced of
>> that at some point.
>> Another decision still needs to be made.
>> I think that everybody now agrees that wherever an argument will be directly
>> used (i.e. "dereferenced") inside the body of the method[1], it is safe to
>> not check for null (since the JVM will throw an NPE).
>> But, whenever an argument is passed for _later_ use (e.g. stored by a
>> constructor or passed to another method), we also all expressed that it is
>> better to fail early if the object is supposed to be non-null. In those
>> cases, checks are not mandatory (since the JVM will throw NPE at some
>> point), but we must agree on how optional checks are to be implemented.
>> 1. The current state of affairs was to throw "NullArgumentException"; in 4.0
>>    this exception will become a subclass of NPE and we can continue to use
>>    it in the same way as now (i.e. possibly providing additional localizable
>>    error messages).
>> 2. The alternative is to directly throw a standard NPE, but without any
>>    message, since it wouldn't be localizable with the support of CM's
>>    "context".
>> So, which of those alternatives do people want to settle on?
> I would prefer 1. If we fail early, do it as precisely as possible.
> Luc
>> Regards,
>> Gilles
>> [1] As opposed to being passed on to another method.
I would also be in favor of #1, so that any exception explicitely
thrown by CM is one of our own exceptions.

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

View raw message