commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
Date Wed, 02 Mar 2011 14:20:45 GMT
On Wed, Mar 02, 2011 at 01:11:48PM +0000, sebb wrote:
> On 2 March 2011 12:50, Gilles Sadowski <> wrote:
> >> > BTW, you can find precedence in the JVM for many methods that throw NPE
> >> > null arguments. I am not saying this is the "right way", since such things
> >> > are subjective and are a matter of design, but many people have concluded
> >> > it's better.
> >>
> >> If the NPE would not be detected until the method has done some other
> >> work, then I can seem why one might want to detect it earlier.
> The above is the trade-off.

Hence you say that the programmer can choose to test or not. Indeed
this is already how it is done in CM: Sometimes there is a check and
sometimes not. So we'd have to state a guideline such that
 "If the NPE would not be detected until the method has done some other
  work, checks for null references should be done at start."
And also that, if the reference is null, a (standard) NPE must be thrown
(without a message, because it wouldn't be localized).

But how much work warrants an additional check?
What if there is no "other work" in the original code but someone adds some
later on (and forget to add the check)?
Overall, I'd think that the advantage is not worth the complication.

> >> And the line number may be insufficient to identify the source of the
> >> NPE - there could be several de-references in a single line.
> >
> > This is the trade-off which I had mentioned here:
> Not really ...
> >> >>> In the end, I'm really not sure what is the best approach for this
> >> >>> particular case. Personally, I'd be happy that the CM code never
> >> >>> for
> >> >>> null and let the JVM throw NPE. This would hugely simplify the
CM code,
> >> >>> albeit at the cost of detecting bad usage a little later. IMHO,
it is not
> >> >>> a
> >> >>> big deal because the bug is that an object is missing somewhere
up the
> >> >>> call
> >> >>> stack, and it should be corrected there...
> >
> .. it may be impossible to determine the true cause of the NPE in some cases.

Even when re-writing the statements on multiple lines for debugging

> So in some cases, it makes sense to check for NPE at the start.

I didn't say otherwise.
But we might want to trade-off the possibility of _easily_ spotting the
failure (this is what I meant by "at the cost of detecting bad usage a
little later") for improved performance.

I still favour the simplest option: no checks for null whatsoever.


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

View raw message