Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mloenko@gmail.com designates
 66.249.92.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=RVeWQr59q8+EZjmURUj84fqWNhaUAppw40wQpwdEXXPI6s3j4BZTCY821O/lDmS8VvaJM3cTWc6q+j0oAFYLHWEbJCqSPiVswYXz+KCFgxMue+bsRaahTASObAC57eFXAjOgYyMZ61O5I+5vK7hktdlTEhSkmPR1Zw5V/p09Pt4=
Message-ID: <906dd82e0603200521t1928efc9h@mail.gmail.com>
Date: Mon, 20 Mar 2006 19:21:11 +0600
From: "Mikhail Loenko" <mloenko@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: NullPointerException
In-Reply-To: <200603191629.20206.chris.gray@kiffer.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <ac85de250603161733i7f43250dhf106447a40d8654a@mail.gmail.com>
	 <46d21a9a0603162347k439ae02dtbe4d86f95278bf50@mail.gmail.com>
	 <200603191629.20206.chris.gray@kiffer.be>

2006/3/19, Chris Gray <chris.gray@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 =3D=3D 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 slowe=
r in
> the null case, but if the RI also throws NPE then these cases should be t=
ruly
> exceptional in the sense that they indicate a programming error or a miss=
ing
> 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 =3D=3D 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
>
>