harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From karan malhi <karan.ma...@gmail.com>
Subject Re: NullPointerException -- This info should be in wiki
Date Mon, 20 Mar 2006 09:08:52 GMT
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
>>>     
>>
>>
>>   
>
>
>

-- 
Karan Singh


Mime
View raw message