On Wed, Sep 12, 2012 at 01:14:32PM +0200, Sébastien Brisard wrote:
> Hi Gilles,
>
> 2012/9/12 Gilles Sadowski <gil...@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.ste...@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).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
