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 Tue, 01 Mar 2011 23:12:36 GMT

> It's a debate that goes on. Josh Bloch in his Effective Java book says NPE
> is perfectly acceptable for bad arguments. So it really depends on your
> perspective what an NPE represents. I prefer Josh's opinion but only because
> every single argument probably creates lots of branch-checking that kills
> cpu pipelining.
> > As far as this issue is concerned (for what i have understood) i believe
> > that one way to separate NULL(s) that occur from the A.P.I. from NULL(s)
> > coming from wrong usage of A.P.I. by a user is the assert technique... I
> > didn't know a lot about it but from what i have read it should be
> > implemented only in the private methods of the A.P.I. Check this link out:
> > "
> >".
> > Another choice is to create a new class that would check all the arguments
> > of every function we are interested in (for example: public
> > checkArguments(Object... args)) [If i have understood correctly the purpose
> > of this issue...]. Any suggestions would be more than welcomed!

NPE is the symptom of a bug.
Using "NullArgumentException" instead of the standard NPE so that the CM
exception hierarchy is singly rooted (the root being "MathRuntimeEception"
in the development version). An advantage is that it is easy to determine
whether an exception is generated by CM. A drawback is that it is
non-standard but this is mitigated by the fact that all other exceptions are
also non-standard (e.g. "MathIllegalArgumentException" instead of IAE).
One has to take into account that we settled on this choice because it makes
it somewhat easier to implement other requirements (namely the localization
of the error messages). It's a compromise (without the localization
requirement, I would have favoured the standard exceptions). And, apart from
avoiding code duplication, this choice has some "features" (which might be
construed as advantages or drawbacks, depending on the viewpoint)...

I'm not sure of what you mean by "branch-checking", but I don't think that
checking for null makes the problem bigger than it would be otherwise, since
CM already checks for many things.

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 checks 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...

Of course, this would mean that MATH-403 should be dropped, the
"NullArgumentException" class removed, and the policy changed to: "Never
check for null references".


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

View raw message