harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: NullPointerException -- This info should be in wiki
Date Mon, 20 Mar 2006 09:30:19 GMT
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



Mime
View raw message