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 Wed, 19 Sep 2012 07:12:02 GMT

2012/9/18 Phil Steitz <>:
> On 9/18/12 12:02 PM, Sébastien Brisard wrote:
>> Hello,
>> 2012/9/17 Gilles Sadowski <>:
>>> 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?
>>> Regards,
>>> Gilles
>>> [1] As opposed to being passed on to another method.
>> I have another question: are we going to little by little remove all
>> null checks that we feel are not absolutely necessary? I would not
>> mind going through this cleaning phase while working on MATH-854.
> I think we should wait to remove the existing null checks until
> 4.0.  This is a significant behavior change, especially for the ones
> that have been in place and documented since 1.x.  Removing the
> checks and allowing NPEs to propagate will break apps that catch IAE.
> Phil
OK. I would like to say that I think this is going the right way: it
is better to have no null checks than incomplete null checks which
provide a false sense of security. For example, have a look to

     * Create a new RealMatrix using the input array as the underlying
     * data array.
     * If an array is built specially in order to be embedded in a
     * RealMatrix and not used directly, the {@code copyArray} may be
     * set to {@code false}. This will prevent the copying and improve
     * performance as no new array will be built and no data will be copied.
     * @param d Data for new matrix.
     * @param copyArray if {@code true}, the input array will be copied,
     * otherwise it will be referenced.
     * @throws DimensionMismatchException if {@code d} is not rectangular
     * (not all rows have the same length) or empty.
     * @throws NullArgumentException if {@code d} is {@code null}.
     * @throws NoDataException if there are not at least one row and one column.
     * @see #Array2DRowRealMatrix(double[][])
    public Array2DRowRealMatrix(final double[][] d, final boolean copyArray) {
        if (copyArray) {
        } else {
            if (d == null) {
                throw new NullArgumentException();
            final int nRows = d.length;
            if (nRows == 0) {
                throw new NoDataException(LocalizedFormats.AT_LEAST_ONE_ROW);
            final int nCols = d[0].length;
            if (nCols == 0) {
                throw new NoDataException(LocalizedFormats.AT_LEAST_ONE_COLUMN);
            for (int r = 1; r < nRows; r++) {
                if (d[r].length != nCols) {
                    throw new DimensionMismatchException(d[r].length, nCols);
            data = d;

I think if you want to be really helpful, a null check should also be
carried out on each d[i]. I think I will leave it as is for now, but
in 4.0, we should certainly remove this null check.
Do you agree?

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

View raw message