You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2004/08/26 16:20:23 UTC
[CONFIGURATION] Semantics change in 1.0-rc1
Hi,
for a long time, doing this:
--- cut ---
import org.apache.commons.configuration.Configuration;
Configuration conf = Turbine.getConfiguration();
String foo = conf.getString("does.not.exist");
--- cut ---
resulted in foo containing null. Somewhere between a random
snapshot and the 1.0-rc release, this changed. Now I get
java.util.NoSuchElementException: 'does.not.exist' doesn't map to an existing object
at ...
which is bad and upsets a lot of software that uses get<XXX>("property")
as a short-cut for get<XXX>("property", null).
I am all for restoring the original behaviour; i.e. returning null
instead of throwing an exception.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CONFIGURATION] Semantics change in 1.0-rc1
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Henning P. Schmiedehausen wrote:
> Please no, no method signature change.
Sorry I wasn't clear enough, that's not what I suggested. The idea is to
add a setThrowExceptionOnMissingProperties(boolean) method to change the
behavior, it would be false by default.
> But we should definitely let the get<xxx> methods return null.
Not every getter return null if the property doesn't exist, getList()
returns an empty list and getStringArray() returns en empty array. It's
more useful than a null value imho.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CONFIGURATION] Semantics change in 1.0-rc1
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
>I suggest adding an optional flag to let the users choose between a
>default value (null or empty values for lists and arrays) and a
>NoSuchElementException. The default behavior would be to return a
>default value.
Please no, no method signature change.
We could do it like Hibernate. They have two different named methods
with the same signature. One returns null, the other throws an
NoSuchElement exception.
getString() --> fetchString() ?
But we should definitely let the get<xxx> methods return null.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CONFIGURATION] Semantics change in 1.0-rc1
Posted by Emmanuel Bourg <sm...@lfjr.net>.
I don't like either the NoSuchElementException for missing properties
when no default value is provided. I searched through CVS, it seems to
have changed last year on October 7th when BaseConfiguration was
refactored to create AbstractConfiguration:
BaseConfiguration, rev 1.3 in the sandbox:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/Attic/BaseConfiguration.java?rev=1.13&view=markup
public String getString(String key)
{
return getString(key, null);
}
AsbtractConfiguration, rev 1.1 in the sandbox:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/Attic/AbstractConfiguration.java?rev=1.1&view=markup
public String getString(String key)
{
String s = getString(key, null);
if (s != null)
{
return s;
}
else
{
throw new NoSuchElementException(
'\'' + key + "' doesn't map to an existing object");
}
}
I'm all for changing this feature for non primitive types, that would be
consistent with the behavior of ExtendedProperties in [collections].
However I wouldn't drop it completely, it's still useful in somes cases.
I suggest adding an optional flag to let the users choose between a
default value (null or empty values for lists and arrays) and a
NoSuchElementException. The default behavior would be to return a
default value.
Emmanuel Bourg
Henning P. Schmiedehausen wrote:
> Hi,
>
> for a long time, doing this:
>
> --- cut ---
> import org.apache.commons.configuration.Configuration;
>
> Configuration conf = Turbine.getConfiguration();
> String foo = conf.getString("does.not.exist");
> --- cut ---
>
> resulted in foo containing null. Somewhere between a random
> snapshot and the 1.0-rc release, this changed. Now I get
>
> java.util.NoSuchElementException: 'does.not.exist' doesn't map to an
> existing object
> at ...
>
> which is bad and upsets a lot of software that uses get<XXX>("property")
> as a short-cut for get<XXX>("property", null).
>
> I am all for restoring the original behaviour; i.e. returning null
> instead of throwing an exception.
>
> Regards
> Henning
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org