[Configuration] Throws ConfigurationException?

[Eric Pugh <ep...@upstate.com>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Configuration] Throws ConfigurationException?

[Emmanuel Bourg <e....@cross-systems.com>]

Eric Pugh wrote:
> 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!

I agree we don't need a checked exception on the various getters. A 
runtime exception is fine, but i don't think it is required for 1.0.

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

The exception inconsistency that i noticed was related to the load/save 
methods in PropertiesConfiguration and DOM4JConfiguration. We should at 
least harmonize the exceptions there before the 1.0 release.


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

That sounds good.

and then maybe we have ConfigurationException extends
> NestableException and ConfigurationRuntimeException extends
> NestableRuntimeException?

Or ConfigurationRuntimeException ?


> 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

Emmanuel Bourg

Re: [Configuration] Throws ConfigurationException?

[__matthewHawthorne <ma...@phreaker.net>]

Eric Pugh wrote:
 > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org