You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by karan malhi <ka...@gmail.com> on 2006/03/20 10:08:52 UTC
Re: NullPointerException -- This info should be in wiki
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
Re: NullPointerException -- This info should be in wiki
Posted by Richard Liang <ri...@gmail.com>.
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
Re: NullPointerException -- This info should be in wiki
Posted by Tim Ellison <t....@gmail.com>.
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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: NullPointerException -- This info should be in wiki
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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
>>>>
>>>
>>>
>>>
>>
>>
>>
>
Re: NullPointerException -- This info should be in wiki
Posted by Anton Avtamonov <an...@gmail.com>.
On 3/20/06, karan malhi <ka...@gmail.com> 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.
>
Absolutely agree. I believe all the valuable decisions made here in
Harmony during discussions must be put on wiki. For this particular
issue "Coding Guidelines" is fine, I think.
--
Anton Avtamonov,
Intel Middleware Products Division