commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
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.

Phil
>
> Gilles
>
>> S├ębastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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


Mime
View raw message