> Or, if we aren't really sure what the Exception handling of the 1.0
> version should be, then skip it (since what we have is "good enuf"),
> and move to a release of 1.0 so we can really think about what we
> want. I think just throwing a ConfigurationException on everything
> that is explicit is going to make the API harder to use and force
> bigger changes on everybodies code that wants to use it.
>
> Just one more thing.. Having said that about ConfigurationException, > I was looking at the ConfigurationFactory and the getConfiguration()
> method throws an Exception. It really should throw a
> ConfigurationException that extends NestableException, and then maybe > we have ConfigurationException extends NestableException and
> ConfigurationRuntimeException extends estableRuntimeException?
I'm not involved in [configuration], but from what I've read, data can be loaded from a number of sources: database, XML, properties files.
RuntimeExceptions are typically used to indicate programmer error. There are plenty of exceptions that can occur under the hood that can naturally occur: SQLException, IOException, SAXException. I don't believe that wrapping these in a RuntimeException would be the best idea.
One possible solution would be to create a ConfigurationRuntimeException and another class, FailFastConfiguration (or something similar) that wraps a configuration instance and wraps all checked exceptions as runtime ones.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
