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 expression:
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
