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