commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject Re: [configuration] Concerns with ConfigurationRuntimeException
Date Thu, 21 Oct 2004 14:01:23 GMT
Ricardo Gladwell wrote:
> Emmanuel Bourg wrote:
>  > Let me know if I missed an exception.
> AFAIK, all actions throw the runtime exception ConversionException.

The typed getters only. getProperty, getKeys, isEmpty, addProperty, 
setProperty, clear, clearProperty, subset, containsKey do not throw 

> 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?

PropertyConfiguration reads from a Map, I think we can assume it 
reliably read it ;)

Logging the errors isn't enough ?

> 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.

What about the flag I suggested to hide ConversionExceptions and return 
the default value if available ?

> 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'm not sure this provides the right reporting mechanism, because the 
application will have to poll this method frequently to check if an 
exception occured. I would prefer a notification mechanism with an event 

> 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

That's the issue to me. Also if we add a checked exception on isEmpty or 
containsKey, the Configuration interface can no longer extend the Map 
interface, I don't want to block this potential evolution.

I believe we can find a compromise preserving the ease of use and 
providing a rigorous error reporting.

Emmanuel Bourg

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

View raw message