commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Gladwell <>
Subject Re: [configuration] Concerns with ConfigurationRuntimeException
Date Thu, 21 Oct 2004 13:11:08 GMT
Emmanuel Bourg wrote:
 > Let me know if I missed an exception.

AFAIK, all actions throw the runtime exception ConversionException.

> I'm not fond of this. It only affects the configurations using an 
> unreliable communication channel to access the properties, that's 
> JNDIConfiguration and DatabaseConfiguration, the most widely used 
> configurations are file based and not affected by this issue, why 
> annoying their users ? Also this may prevent us from making 
> Configurations implement the Map interface, I still want to try this.

I would argue that all communcation channels have the potential to be 
unreliable especially when you consider the IO API can be extended to 
read/write data from  variety of source types. We cannot exclude the 
possiblity of, for example, reading configuration information over 
(unreliable) network connections. I don't this is an argument against 
reporting exceptions in the underlying layer. Otherwise, would the 
various IOException and SQLException also be runtime exceptions?

I think, rather than force users to exit their programs on a 
configuration error we should give them the option of either exiting 
gracefully themselves or handling configuration exceptions unless we can 
guanrantee that no exceptions will be thrown be by the code under all 
circumstances (i.e. if disk is full, if hard disk is corrupted, etc) in 
which case *we* have to handle the exception and recover from it. There 
are many reasons for doing this, more importantly, so that users can 
handle and recover from configuration read/write exceptions themselves.

Another option would be to create an exception reporting mechanism 
within the Configuration interface. Perhaps a method call 
getExceptionsThrown() that returns a list of exceptions thrown during 
the last few operations. Of course, this does mean that we are 
re-creating the exception throwing mechanism implemented within Java itself.

> I don't want to declare a ConfigurationException on every method of the 
> Configuration interface, logging data access errors is fine imho, but 
> there are some unexpected and undocumented runtime exceptions that 
> should be removed (the most important is in 
> JNDIConfiguration.getKeys()). The case of ConversionException should 
> also be examined.

It depends on why you are opposed to adding ConfigurationException to 
all methods declartions in Configuration. If it's because it would 
clutter the code with various try/catch blocks for users then I would 
argue that this should not be an issue: reporting and handling 
exceptions is a hassle but there is a very specific reason we have them. 
I think the users would object more to the fact that

Kind regards,
-- Ricardo

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

View raw message