On 3/17/06, Karan Malhi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Some of the methods/constructors in the API throw a NullPointerException
> when a null is passed in as an argument. The spec doesnt say anything that
> the method/constructor should throw a NullPointerException, neither does it
> say anything about how the method/constructor should behave when a null is
> passed in.
> What should be the approach in that case?
> 1. Could we check for null within a method and handle it so that the method
> does not unneccessarily throw an NPE (this would differ from how the spec
> would behave) or
> 2. should we allow the method to throw an NPE if the spec method also throws
> it?
Hi,
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).
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.
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
