On Wed, Mar 02, 2011 at 01:11:48PM +0000, sebb wrote: > On 2 March 2011 12:50, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > >> > BTW, you can find precedence in the JVM for many methods that throw NPE > >> > on > >> > 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 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... > > > > .. 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 purposes? > 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. Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
