avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Configuration getChild() never returns null
Date Mon, 12 Nov 2001 14:01:27 GMT
Jeff Turner wrote:
> 
> 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?

Just to set the record straight:

The Configuration object will throw a ConfigurationException if you call
c.getChild("foo", false) and "foo" does not exist.

The whole "create child configuration" approach was not to avoid
NullPointerExceptions, but to cut down on the complexity of exception
handling in the configure() code.

This "feature" allows you to do things like this:

int port = c.getChild("serverinfo").getChild("port").getValueAsInteger(80);
String host = c.getChild("serverinfo").getChild("host").getValue("localhost");

That way you can have defaulted values (like the getValueAsInteger with a param),
and not have to put complex try/catch heirarchies.

Also, the difference between getValue() and getValue("value") is that if there is
no value, the first will throw a ConfigurationException, and the other will return
the default value.  The same with the Attribute methods.


> 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) {
>         // ..
> }

This would have to be rewritten as:

try {
    Configuration c = conf.getChild("foo", false);
} catch (ConfigurationException ce) {
    // the value did not exist.
}


We all know that Exception handling is slow, and should be the exception,
not the rule.

> Anyway, if it's being used in the way you say, the issue probably isn't
> worth breaking everyone's code over.

It definitely isn't.


-- 

"Those who would trade liberty for
 temporary security deserve neither"
                - Benjamin Franklin

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message