commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [configuration] NoSuchElementException vs null
Date Wed, 16 Jun 2004 20:53:07 GMT
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 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!

Now, we could make NoSuchElementException extend RuntimeException (if it
doesn't already) so that you don't have to have a try catch loop unless you
need it.  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.

Eric

> -----Original Message-----
> From: Emmanuel Bourg [mailto:smanux@lfjr.net]
> Sent: Wednesday, June 16, 2004 8:03 PM
> To: Jakarta Commons Developers List
> Subject: [configuration] NoSuchElementException vs null
>
>
> While harmonizing the exception thrown by the various methods of the
> Configuration interface I found out that getList was implemented
> differently in CompositeConfiguration and AbstractConfiguration.
> AbstractConfiguration throws a NoSuchElementException if the key doesn't
> exist in the configuration, and CompositeConfiguration returns an empty
> List in this case.
>
> This made me wonder why we want to throw a NoSuchElementException in the
> first place, an empty List isn't that bad after all. Obviously this
> exception is thrown to make the method look & feel like the other getXXX
> methods, but this make sense only for the primitive types since
>
> getByte(String key);
>
> cannot return null. For the non primitive types (String, BigInteger,
> BigDecimal, List, and maybe later Date, URL, Locale...) a null or an
> empty value would be more convenient. It would spare a cumbersome
> try/catch block:
>
> try {
>      String s = config.getString("key");
> } catch (NoSuchElementException e) {
>      // do something
>      ...
> }
>
> or an additional parameter to specify a default value:
>
> String s = config.getString("key", null);
> if (s == null) {
>      // do something
>      ...
> }
>
> It would be easier to write directly:
>
> String s = config.getString("key");
> if (s == null) {
>      // do something
>      ...
> }
>
> What do you think?
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message