You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jeff Turner <je...@socialchange.net.au> on 2001/11/10 11:22:22 UTC
Configuration getChild() never returns null
Hi,
The javadocs for Configuration state:
"The contract surrounding the Configuration is that once it is
created, information never changes."
There are two variants of getChild:
Configuration getChild(java.lang.String child)
Configuration getChild(java.lang.String child, boolean createNew);
Now I'm wondering, what's the "createNew" attribute for? Why would you
want to create a new Configuration, when you can't do anything with it
(it's read-only).
Even more surprising is that for the single arg version, "createNew" is
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?
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Configuration getChild() never returns null
Posted by Peter Donald <do...@apache.org>.
On Sat, 10 Nov 2001 21:47, Jeff Turner wrote:
> > > 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?
maybe. Not sure. It was originally implemented like this when we were talking
about default values for things in config tree. Then people started using the
below construct and we got stuck with it ;)
> What can be done with an empty 'c' object?
s =
getChild("foo").getChild("bar").getChild("baz").getValue("default-value");
will always return a string value (using "default-value" - even if a
intermediate config doesn't exist.
>
> 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.
I got a new funky acronym for that - it's BCS - Backwards Compatability
Syndrome ;]
--
Cheers,
Pete
---------------------------------------------
We shall not cease from exploration, and the
end of all our exploring will be to arrive
where we started and know the place for the
first time -- T.S. Eliot
---------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Configuration getChild() never returns null
Posted by Berin Loritsch <bl...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Configuration getChild() never returns null
Posted by Jeff Turner <je...@socialchange.net.au>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Configuration getChild() never returns null
Posted by Peter Donald <do...@apache.org>.
On Sat, 10 Nov 2001 21:22, Jeff Turner wrote:
> Hi,
>
> The javadocs for Configuration state:
>
> "The contract surrounding the Configuration is that once it is
> created, information never changes."
>
> There are two variants of getChild:
>
> Configuration getChild(java.lang.String child)
> Configuration getChild(java.lang.String child, boolean createNew);
>
> Now I'm wondering, what's the "createNew" attribute for? Why would you
> want to create a new Configuration, when you can't do anything with it
> (it's read-only).
>
> Even more surprising is that for the single arg version, "createNew" is
> 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");
rather than
Configuration foo = getChild("foo");
if( null != foo )
{
Configuration bar = getChild("bar");
if( null != bar )
{
c = getChild("baz");
}
}
--
Cheers,
Pete
----------------------------------------
Whatever you do will be insignificant,
but it is very important that you do it.
--Gandhi
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>