Hi all,
A while ago we discussed 1.0 requirements that are left. And at this point,
all have been finished except changing the api to throw a
ConfigurationException.
Now, I am thinking about how to implement this, and am not too keen on the
idea of ConfigurationException being a non runtime explicit Exception.
Primarily because I expect Configuration to always work, and so when I say:
String s = Configuration.getString("my.string");
I don't want to be surrounding it with try/catch for ConfigurationException.
Indeed, I know what will happen, it will join the other methods that all
throw Exception because if a ConfigurationException happens, there is no way
for me to deal with it, except by crashing out the app!
So, if we want a ConfigurationException, why don't we make it a extension of
NestableRuntimeException (from commons-lang) and declare that we throw that?
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
NestableRuntimeException?
I really want to get to the 1.0 release of Configuration soon, especially
now that we have a database backed exceptions plus all the goodies in
ConfigurationFactory!
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
