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 Wed, 12 Sep 2012 14:20:48 GMT
On 9/12/12 5:14 AM, Sébastien Brisard wrote:
> 2012/9/12 Gilles Sadowski <>:
>> On Wed, Sep 12, 2012 at 01:14:32PM +0200, Sébastien Brisard wrote:
>>> Hi Gilles,
>>> 2012/9/12 Gilles Sadowski <>:
>>>> On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
>>>>> Hi Phil,
>>>>> 2012/9/10 Phil Steitz <>:
>>>>>> On 9/10/12 11:47 AM, Sébastien Brisard wrote:
>>>>>>> Hi
>>>>>>> What should I do there?
>>>>>>> I'm trying to work on MATH-854. It turns out that FieldElement<T>.add
>>>>>>> throws a NAE. Should I catch it below, and rethrow it with a
>>>>>>> detailed message (including the entry index)?
>>>>>> IMO, yes.
>>>>>> I would also check v itself and add to the javadoc contract that
>>>>>> is thrown if v is null.  This is not consistently done in [math],
>>>>>> though, and rarely in the linear package, so I am OK just letting
>>>>>> the NPE propagate if v is null.   It is a little awkward that v
>>>>>> itself being null leads to NPE, but a component of it null leads
>>>>>> MIAE.
>>>>> I agree with you, it feels weird. I found a better way: we need to
>>>>> make sure that entries of FieldVector can *never* be null. This means
>>>>> checking for null in setters, constructors and the likes. What do you
>>>>> think?
>>>> That would certainly simplify some code.
>>>> But (devil's advocate) should we consider that some people may rely on the
>>>> possibility to set "null" entries?
>>> Yes, didn't think of that. However, the javadoc does not specify that
>>> null is allowed. So referring to earlier discussions, that should mean
>>> that it is forbidden... I'm stretching the argument a little bit, I
>>> know.
>> That's fine with me. In the sense that it is IMHO a _developer_'s choice:
>> It's a statement about the library ("We decide for consistency and
>> robustness reasons, that "null" is forbidden").
>> I contend that it is the same kind of argument that led most of us to prefer
>> immutable instances (even if some users might want to have mutable ones).
> Fine, then. I'll implement null checks in all setters and
> constructors, so that it is guaranteed that null will never be met
> elsewhere.
> I will modify the javadoc of the interface to clearly state that null
> values should not be accepted, and that a MNAE should be thrown in
> that case.

+1 Good idea that adds robustness.

It is not ideal, but as a general principle where the javadoc is
underspecified, it is IMO fair game to explicitly state
preconditions and add checks for them.  This amounts to fully
specifying the API contract.  Code that relies on undocumented
behavior can break in this case.  This is why it is best to specify
the contract as fully as possible.  We need to be kind and practical
when applying this principle though.  Assumptions that *lots of
users* are likely to be making made suddenly no longer true should
be avoided.  The present case is unlikely to be a practical problem
for anyone.

I know this is a little of a sore subject, but in this and other
cases where arguments violate documented preconditions, I think we
should throw IAE, which means MNAE is only appropriate as long as it
continues to subclass our surrogate for IAE - MIAE.

If I sound hard-headed here, it would be great if someone could
explain to me what is different about null arguments at the point of
method activation in an API that explicitly disallows them. 
Consider, e.g. an empty array or array indices that will lead to
index out of bounds errors in APIs that take arrays.  What is so
different about null?  All are bad arguments violating API contract,
all detected at method activation time -> IAE.

> Sébastien
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message