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 Wed, 12 Sep 2012 12:14:54 GMT
2012/9/12 Gilles Sadowski <gilles@harfang.homelinux.org>:
> On Wed, Sep 12, 2012 at 01:14:32PM +0200, Sébastien Brisard wrote:
>> Hi Gilles,
>>
>> 2012/9/12 Gilles Sadowski <gilles@harfang.homelinux.org>:
>> > On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote:
>> >> Hi Phil,
>> >>
>> >> 2012/9/10 Phil Steitz <phil.steitz@gmail.com>:
>> >> > 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 more
>> >> >> detailed message (including the entry index)?
>> >> >
>> >> > IMO, yes.
>> >> >
>> >> > I would also check v itself and add to the javadoc contract that IAE
>> >> > 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 to
>> >> > 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.
Sébastien


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message