Yep, these guidelines should be on the website -- Karan please submit a
patch.
Regards,
Tim
Geir Magnusson Jr wrote:
> Please, but how about a document for the website?
>
> 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.
>>
>> 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
