karan malhi wrote:
Hi,
This information should be put in the wiki under "Coding Guidelines"
or "How do I " kind of a section. I think that a lot of discussion
gets buried in the mailing list and then the same issue crops up
again. I am willing to undertake updating the wiki with this
information if you all agree.
Good idea. ;-)
Paulex Yang wrote:
Chris Gray wrote:
On Friday 17 March 2006 08:47, Anton Avtamonov wrote:
Actually null-processing and corresponding NPEs are very very often
omitted from the spec.
I would say that according to the guidelines Paulex proposed (and as I
understood we agreed on) we should be RI-compatible in this case.
Really, spec doesn't say anything regarding null-processing and
therefore throwing NPE in this case does *not* contradict to the spec.
Having NPE we will be better RI-compatible and stay on the same
position in the spec-compatibility (since it is silent).
Therefore I suggest to be RI-compatible by default in all cases when
spec keep silence. I believe it well suites Paulex guidelines (please
correct me if I wrong).
+1
Talking about how particulary we should throw NPE I'm not sure what to
advise: in many cases RI just produces them automatically when actual
call like null.someMehtod() occurs. To provide better notation we can
do that directly, i.e.
if (someVar == null) {
throw NullPointerException("some valuable message")
}
I'm not really sure what is better and would like to know what others
think about.
I prefer to let these things happen automatically whenever possible.
Introducing an explicit check adds extra bytecodes and probably
extra CPU cycles in the non-null case. On some VMs null.someMethod()
might be slower in the null case, but if the RI also throws NPE then
these cases should be truly exceptional in the sense that they
indicate a programming error or a missing resource. OTOH if the RI
treats a null argument as a normal case then this should be
implemented using 'if (someVar == null)', not by catching a NPE(!).
My opinion is:
either is fine, the only principle is the exception order must be
compliant with RI, if it can be happen automatically, great. if can
not, then the explicit check is necessary, while the performance
should be the second consideration.
Chris
Btw, when we will work on documentation (javadoc) I think we should
append references to the standard Sun API in the methods javadoc with
the direct info about null-processing and NPE if a method can produce
it (when it is missing from the original spec of course).
--
Anton Avtamonov,
Intel Middleware Products Division
--
Richard Liang
China Software Development Lab, IBM
