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/17 02:33:09 UTC
NullPointerException
Hi,
Some of the methods/constructors in the API throw a NullPointerException
when a null is passed in as an argument. The spec doesnt say anything that
the method/constructor should throw a NullPointerException, neither does it
say anything about how the method/constructor should behave when a null is
passed in.
What should be the approach in that case?
1. Could we check for null within a method and handle it so that the method
does not unneccessarily throw an NPE (this would differ from how the spec
would behave) or
2. should we allow the method to throw an NPE if the spec method also throws
it?
--
Karan Malhi
Re: NullPointerException
Posted by Tim Ellison <t....@gmail.com>.
Anton Avtamonov wrote:
> On 3/17/06, Karan Malhi <ka...@gmail.com> wrote:
>> Hi,
>>
>> Some of the methods/constructors in the API throw a NullPointerException
>> when a null is passed in as an argument. The spec doesnt say anything that
>> the method/constructor should throw a NullPointerException, neither does it
>> say anything about how the method/constructor should behave when a null is
>> passed in.
>> What should be the approach in that case?
>> 1. Could we check for null within a method and handle it so that the method
>> does not unneccessarily throw an NPE (this would differ from how the spec
>> would behave) or
>> 2. should we allow the method to throw an NPE if the spec method also throws
>> it?
>
> Hi,
>
> 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).
I agree.
> 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 think either is fine. We have tended to let NPE be thrown 'naturally'
and only tested for it if we need to get the order of exceptions right
wrt the RI.
> 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).
Agreed.
Regards,
Tim
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: NullPointerException
Posted by Nikolay Kuznetsov <ni...@gmail.com>.
I have reminiscence that the general rule is that unless otherwise
stated methods and constructors will throw NPE if passed null
argument.
Unfortunately I have not found more general place in javadoc stating
this except following citing from java.util.logging package
description:
"In general, unless otherwise noted in the javadoc, methods and
contructors will throw NullPointerException if passed a null argument.
The one broad exception to this rule is that the logging convenience
methods in the Logger class (the config, entering, exiting, fine,
finer, finest, log, logp, logrb, severe, throwing, and warning
methods) will accept null values for all arguments except for the
initial Level argument (if any)."
I understand this as that in general methods and constructors do not
check if arguments passed are null or not, otherwise javadoc specifies
the exact behavior. Of course there are exceptions which are not
stated in javadoc, but those exceptions should be checked on case by
case basis.
Also I think that exact checks for null arguments are not necessary
(except those cases when they have special meaning) and moreover could
cause performance impact.
--
Nikolay Kuznetsov,
Intel Middleware Products Division
Re: NullPointerException
Posted by Chris Gray <ch...@kiffer.be>.
On Monday 20 March 2006 09:41, Paulex Yang wrote:
> My opinion is:
> either is fine, the only principle is the exception order must be
> compliant with RI,[...]
Good point. I agree.
Chris
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
Re: NullPointerException
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/3/20, Chris Gray <ch...@kiffer.be>:
> On Monday 20 March 2006 14:21, Mikhail Loenko wrote:
> > 2006/3/19, Chris Gray <ch...@kiffer.be>:
> > > 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.
> >
> > I do not agree that performance in case of 'exceptional' behavior
> > is not important.
> >
> > Would you use for example a browser that hangs your machine up for an hour
> > if you type wrong URL? Or if it crashes when some site misses some gif
> > file?
>
> <aside>I can remember browsers that did that (or at least waited for DNS to
> time out).</aside>
>
> I never claimed that performance in case of 'exceptional' behavior is not
> important. However it is less important than performance in the normal case;
> for example it would not make sense for Apache to optimise the processing of
> mistyped URLs at the expense of correctly-typed ones. Ideally the most
My experiments have shown that additional check for null is insignificant
while accessing time of a null address is substantial.
> frequently executed code paths should also be the shortest.
>
> There are cases where a 'catch' clause can be executed very often, such as the
> ClassNotFoundException which is thrown when a class loader delegates to its
> parent and the parent does not find the class. In such cases one might
> consider optimising this path; but NPEs generally do not fall into this
> category, they most often indicate a programmer error (not user error) or the
Actually, we are developing runtime environment, not an ordinary application
and thus those programmers who make errors and write poor-designed code are
all our users, clients, and valued customers
We should take care of them and make their applications as fast as we can.
Thanks,
Mikhail
> absence of some required resource (installation error). That is what I meant
> by "truly exceptional".
>
> Respectfully,
>
> Chris
>
> --
> Chris Gray /k/ Embedded Java Solutions BE0503765045
> Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
> chris.gray@kiffer.be +32 3 216 0369
>
>
Re: NullPointerException
Posted by Chris Gray <ch...@kiffer.be>.
On Monday 20 March 2006 14:21, Mikhail Loenko wrote:
> 2006/3/19, Chris Gray <ch...@kiffer.be>:
> > 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.
>
> I do not agree that performance in case of 'exceptional' behavior
> is not important.
>
> Would you use for example a browser that hangs your machine up for an hour
> if you type wrong URL? Or if it crashes when some site misses some gif
> file?
<aside>I can remember browsers that did that (or at least waited for DNS to
time out).</aside>
I never claimed that performance in case of 'exceptional' behavior is not
important. However it is less important than performance in the normal case;
for example it would not make sense for Apache to optimise the processing of
mistyped URLs at the expense of correctly-typed ones. Ideally the most
frequently executed code paths should also be the shortest.
There are cases where a 'catch' clause can be executed very often, such as the
ClassNotFoundException which is thrown when a class loader delegates to its
parent and the parent does not find the class. In such cases one might
consider optimising this path; but NPEs generally do not fall into this
category, they most often indicate a programmer error (not user error) or the
absence of some required resource (installation error). That is what I meant
by "truly exceptional".
Respectfully,
Chris
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
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 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 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
Re: NullPointerException -- This info should be in wiki
Posted by karan malhi <ka...@gmail.com>.
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
Posted by Paulex Yang <pa...@gmail.com>.
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
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: NullPointerException
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/3/19, Chris Gray <ch...@kiffer.be>:
> 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.
I do not agree that performance in case of 'exceptional' behavior
is not important.
Would you use for example a browser that hangs your machine up for an hour if
you type wrong URL? Or if it crashes when some site misses some gif file?
Ideally each usage scenario must work just fine
Thanks,
Mikhail
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(!).
>
> 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
>
> --
> Chris Gray /k/ Embedded Java Solutions BE0503765045
> Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
> chris.gray@kiffer.be +32 3 216 0369
>
>
Re: NullPointerException
Posted by Chris Gray <ch...@kiffer.be>.
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(!).
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
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
Re: NullPointerException
Posted by Anton Avtamonov <an...@gmail.com>.
On 3/17/06, Karan Malhi <ka...@gmail.com> wrote:
> Hi,
>
> Some of the methods/constructors in the API throw a NullPointerException
> when a null is passed in as an argument. The spec doesnt say anything that
> the method/constructor should throw a NullPointerException, neither does it
> say anything about how the method/constructor should behave when a null is
> passed in.
> What should be the approach in that case?
> 1. Could we check for null within a method and handle it so that the method
> does not unneccessarily throw an NPE (this would differ from how the spec
> would behave) or
> 2. should we allow the method to throw an NPE if the spec method also throws
> it?
Hi,
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).
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.
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
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi Karan,
Actually there is a number of conditions that affect final case-by-case made
decision:
1. The spec might say
a) that SomeException (SE) is thrown in case of null arg
b) that SE is thrown in case of "invalid" arg
c) nothing about wrong args
2. The class and method under consideration might pass argument and control
to some user's or third-party class (like some handler or crypto algorithm) and
RI's NPE happens originally there. In this case we should study the
spec for that
class, implications of null arguments in that class and case-by-case decide.
I think being compatible with RI is by-default decision, and in
the majority of cases is the right decision to take.
BTW, explicit check of an arg for null would unnoticably slow down execution
in case of non-null argument but would siginificantly speed it up in
case of null.
Once again, decision is to be made case-by-case
Thanks,
Mikhail