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? Gilles > > Sébastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
