harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: NullPointerException -- This info should be in wiki
Date Mon, 20 Mar 2006 13:07:08 GMT
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
>>>>     
>>>
>>>
>>>   
>>
>>
>>
> 

Mime
View raw message