commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [Math] About "NullArgumentException"
Date Sun, 09 Sep 2012 22:44:07 GMT
On 9/9/12 3:26 PM, Gilles Sadowski wrote:
> On Sun, Sep 09, 2012 at 09:16:51AM -0700, Phil Steitz wrote:
>> On 9/9/12 4:34 AM, Gilles Sadowski wrote:
>>> Hi.
>>> Further discussion on the JIRA page
>>> cannot reach a consensus on solving the issue that raised this thread.
>>> The proposal was that CM never checks for "null" and lets the JVM do it (and
>>> thus throw the standard NPE).
>>> Phil wants to retain some null checks but opposes to throwing a NPE without
>>> a "detailed message".
>>> The localization mechanism being implemented in "ExceptionContext", we
>>> cannot throw a standard NPE (since the error message won't be localized).
>>> For a consistent behaviour (as seen from the caller), we would have to
>>> implement a subclass of the standard NPE: callers could do
>>>  try {
>>>    // Call CM
>>>  } catch (NullPointerException e) {
>>>    // Handle NPE (raised by the JVM _or_ by CM).
>>>  }
>>> However, this breaks the consensus we arrived at (for v4.0) about CM
>>> throwing only subclasses of "MathRuntimeExceprion" (singly rooted hierarchy).
>>> Phil proposes to throw MathIAE (IMO, it must be the specific
>>> "NullArgumentException"), but this breaks the above use-case: Users have to
>>> do
>>>  try {
>>>    // Call CM
>>>  } catch (NullPointerException e) {
>>>    // Handle NPE (raised by the JVM).
>>>  } catch (NullArgumentException e)
>>>    // Handle NPE (raised by CM).
>>>  }
>>> showing blatantly that CM is not consistent: sometimes it lets a JVM
>>> exception propagate, and sometimes it catches the problem eralier and throws
>>> an exception that is not in the same hierarchy (NPE vs IAE or, in 4.0,
>>> "MathRuntimeException").
>>> This is the current state of affairs, and I think that it is not
>>> satisfactory. [As proven by this issue having recurred two or three times
>>> already.]
>>> In light of this, I propose that either
>>> * Phil changes his mind (no check for null performed in CM code), or
>>> * we make an exception to the singly-rooted hierarchy just for
>>>   "NullArgumentException" (which, in 4.0, would become a subclass of the
>>>   standard NPE).
>> Why not just leave things alone [...]
> For the reason I gave above: the inconsistent/non-existent policy will make
> the issue recur sooner or later, as it happened now with S├ębastien, as it
> happened with me when I first signalled the burden of checked excpetions and
> later when we agreed about MathRuntimeException, then changed again, to come
> back again now, to where we were almost two years ago (IIRC)...
>> - i.e., let some APIs document null
>> handling and throw IAE at the point of method invocation when
>> supplying a null violates the documented API contract?
> The answer to that question is in the previous post.
>> We can leave the (needless, IMO) NullArgumentException as a subclass
>> of MathIAE in place, or drop it and throw MathIAE directly in these
>> cases.
> "NullArgumentException" is about as needless as any subclass of "Exception"
> or "RuntimeException". Either we use inheritance for what it's primarily
> meant or we choose another, non-OO, language.
> This is going in circles; some people will drop from the discussion (or
> already did) and some time from now, someone will "rediscover" this, among
> other little defects of CM. These are worth correcting, but not worth
> discussing endlessly.
> Let's just have all people here provide their preference and be done with
> it.
> Gilles
> P.S. Is there an occurrence in CM, where a method can be passed a null
>      argument?

Yes.   One example is the constructor for EmpiricalDistribution that
takes a RandomGenerator as argument.  If a null is supplied, the
constructor does not complain and the lazy initialization works as
though the argumentless constructor had been used and a JDK random
generator is created.  There are other similar examples, mostly
constructors, IIRC.

>> Phil
>>> The second option cares for all the various positions _except_ the
>>> singly-rooted hierarchy.
>>> Regards,
>>> Gilles
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message