Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 24309 invoked from network); 10 Nov 2001 10:42:22 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 10 Nov 2001 10:42:22 -0000 Received: (qmail 29553 invoked by uid 97); 10 Nov 2001 10:42:34 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 29531 invoked by uid 97); 10 Nov 2001 10:42:33 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 29518 invoked from network); 10 Nov 2001 10:42:32 -0000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p553-apx1.syd.ihug.com.au [203.173.142.45] claimed to be expresso.localdomain Date: Sat, 10 Nov 2001 21:47:20 +1100 From: Jeff Turner To: Avalon Developers List Subject: Re: Configuration getChild() never returns null Message-ID: <20011110214720.E2422@socialchange.net.au> Mail-Followup-To: Avalon Developers List References: <20011110212222.D2422@socialchange.net.au> <200111101026.fAAAQG206583@mail016.syd.optusnet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200111101026.fAAAQG206583@mail016.syd.optusnet.com.au> User-Agent: Mutt/1.3.23i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sat, Nov 10, 2001 at 09:23:25PM +1100, Peter Donald wrote: > On Sat, 10 Nov 2001 21:22, Jeff Turner wrote: [..] > > true. So getChild("foo") won't return null even if no child "foo" > > exists. I suppose this prevents inadvertent NPEs, but also prevents > > useful tests like: > > > > if (conf.getChild("foo") != null) { > > // .. > > } > > > > Is there a reason for returning an empty child Configuration, or is this > > a bug? > > Its a feature so that we can support a pattern like > > c = getChild("foo").getChild("bar").getChild("baz"); If /foo/bar exists, that will work under either system. If /foo or /foo/bar doesn't exist, isn't it a logical error for the program to assume it does? What can be done with an empty 'c' object? And to gain this "feature", one gives up the logical way to check for a subelement's presence (a null check). Though I guess it can still be done with: if (conf.getChid("foo", false) == null) { // .. } Anyway, if it's being used in the way you say, the issue probably isn't worth breaking everyone's code over. --Jeff > -- > Cheers, > > Pete > > ---------------------------------------- > Whatever you do will be insignificant, > but it is very important that you do it. > --Gandhi > ---------------------------------------- > -- To unsubscribe, e-mail: For additional commands, e-mail: