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 Thu, 06 Sep 2012 13:23:33 GMT
On 9/6/12 5:16 AM, Gilles Sadowski wrote:
> Hi.
>>>>>> [...]
>>>> I was about to start a new thread too, but refrained to do so for lack
>>>> of knowledge on the history of this particular exception.
>>>> Check for null is unevenly enforced througout the library, which --to
>>>> me-- suggests we shouldn't do it at all and contend with NPE. There is
>>>> one potential use, though. I think we should check for null when the
>>>> NPE might occur in a different method.
>>>> This is what happens with new Incrementor(int,
>>>> MaxCountExceededCallback) : cb is just copied, and fields of cb are
>>>> invoked elsewhere: in that case, checking for null does make sense.
>>> I think even there we could rely on the JVM, for simplicity.
>> Do you mean that we should do nothing, and let NPE occur "naturally"?
> I'd think we should opt for this.
>> The origin of the problem might then be difficult to identify.
> That's true. But the reason of the problem is an "obvious" bug
> (uninitialized variable).
> The exception may be raised further down the call sequence, but the stack
> trace will provide a one way road to discover the source of the problem.
>> Or maybe you meant that we check for null in that case, but throw NPE
>> instead of our own MathNullArgument?
> No, it sure is simpler to do nothing in CM. :-)
> Otherwise, we'll have to check every reference (for consistency).
>> I would be in favor of the second option. On the other hand it's
>> difficult to check that it's consistently applied throughout our code,
>> and I can see your point in doing nothing.
> So, do we agree?

I would rather fully document what the API does on nulls (which we
do in a lot of places now), but can live with the "go boom" for this
in some (most?) places if that is the consensus of others.  I would
prefer at least not to rip out the null checks that we have in a lot
of places in the stats package.  As a user, I would rather get an
IAE with informative message when I pass a not allowed null than an
untrapped NPE from somewhere a few layers down in the stack.  I
would like to preserve the way the code that does null checks today
works.  Other than that, I am OK dropping the custom [math] exception.

> Gilles
>> S├ębastien
>> ---------------------------------------------------------------------
>> 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