Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 2 Mar 2011 13:50:34 +0100
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [Math - 403] Never propagate a "NullPointerException"
 resulting from bad usage of the API
Message-ID: <20110302125034.GO22814@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: <AANLkTikfv8NTprVs0Xso9Kpm+j_5YT=1KoZ=+e2O68t=@mail.gmail.com>
 <AANLkTi=VaTw2bfvADOWgyxM0RLNU6BF7ki-8F_Gadj5=@mail.gmail.com>
 <20110301231236.GI22170@dusk.harfang.homelinux.org>
 <514CE0C1587E41418D26F4AE7EBAC6EA@BillPC>
 <AANLkTi=rT=ums11F_56A=tQuUnQW9kLoscF58xo95TGL@mail.gmail.com>
 <AANLkTikg0EtBcwKN8rfCqoG9wB_die+VLPppCiBT-6w3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AANLkTikg0EtBcwKN8rfCqoG9wB_die+VLPppCiBT-6w3@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-DCC-scarlet.be-Metrics: sif 20002; Body=1 Fuz1=1 Fuz2=1

> > BTW, you can find precedence in the JVM for many methods that throw NPE on
> > null arguments. I am not saying this is the "right way", since such things
> > are subjective and are a matter of design, but many people have concluded
> > it's better.
> 
> If the NPE would not be detected until the method has done some other
> work, then I can seem why one might want to detect it earlier.
> 
> And the line number may be insufficient to identify the source of the
> NPE - there could be several de-references in a single line.

This is the trade-off which I had mentioned here:

> >>> In the end, I'm really not sure what is the best approach for this
> >>> particular case. Personally, I'd be happy that the CM code never checks
> >>> for
> >>> null and let the JVM throw NPE. This would hugely simplify the CM code,
> >>> albeit at the cost of detecting bad usage a little later. IMHO, it is not
> >>> a
> >>> big deal because the bug is that an object is missing somewhere up the
> >>> call
> >>> stack, and it should be corrected there...


Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org