Hi. > 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: > > " > > http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html";. > > 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". Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
