commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject Re: [configuration] NoSuchElementException vs null
Date Thu, 17 Jun 2004 14:38:38 GMT
Eric Pugh wrote:

> The thing is though that I think that in typical use, the
> NoSuchElementException wouldn't be caught..  Instead, it would get thrown up
> the call stack until somethign could properly handle it.

I agree, no one is going to catch this exception, it's easier to use 
containsKey to check if the property exists.

> i see this exception only occuring when someone has messed up the
> configuration, versus a normal kind of exception that we would want to catch
> and deal with.  I would rather get an informative NoSuchElementException
> versus an non informative NullPointerException!

I think there are two use cases:

1. the configuration error you described, the user didn't anticipate the 
possibility of a missing property and used the get<Type> method without 
default value, a NoSuchElementException is certainly more descriptive 
but a NullPointerException is common and easy to track back.

2. the developper knows the property can be missing and he anticipated a 
null value. By removing the exception he can write directly the shorter 

String s = config.getString("key");

instead of:

String s = config.getString("key", null);

If he thought getString was consistent with getProperty and returned 
null for missing values, he'll be surprised to receive an exception. 
This case is likely for people converting code using 
java.util.Properties to [configuration]. They will naturally translate this:

String s = props.getProperty(key);

into this:

String s = config.getString(key);

and I bet they will come back to this line of code sooner or later, 
raging against [configuration], because they didn't anticipate their 
application would break on a NoSuchElementException.

> Now, we could make NoSuchElementException extend RuntimeException (if it
> doesn't already)

Yes it's already a RuntimeException.

> Configuration (as of this 1.0 version) is viewed as a relatively
> static entity that gets started up when the app starts up, and then stays
> more or less the same.  I think that the 2.0 version of Configuration with
> loaders and listeners and such will be a much more dynamic beast where these
> kinds of changes may be more appropriate.

Well at this point I still haven't solved my main issue: do we want to 
throw an exception on getList() if the property doesn't exist? My 
preference is to not throw a NoSuchElementException and return an empty 
List instead, this will be similar to getStringArray which returns an 
empty array if the property is missing.

The case of the other non primitive types (String, BigInteger and 
BigDecimal) can be settled later.

Emmanuel Bourg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message