commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Gladwell <>
Subject Re: [configuration] handling exceptions in AbstractConfiguration implementations
Date Wed, 06 Oct 2004 17:40:42 GMT
Emmanuel Bourg wrote:
> I don't want to sound harsh, but what is the added value of using 
> Hibernate here for such a simple data structure ? A direct JDBC 
> implementation is good enough and spare a 1.5MB dependency.

Nothing, AFAIK: the only reason I developed it was because I was using 
Hibernate in my own application and I just thought it would be nice if 
all database calls, including those for configuration, could be 
re-directed through the Hibernate API to take advantage of it's caching, 
logging, etc.

I only posted it here to demonstrate the issue I was explaining and 
because of the interest - otherwise it will just sit in my project never 
reaching the wider world. Do what thou wilt with it :)

Kind regards,
-- Ricardo

> Ricardo Gladwell wrote:
>> Hi All,
>> I'm currently developing a sub-class of the AbstractConfiguration 
>> classthat uses Hibernate to access configuration properties 
>> (unimaginatively called Hibernate Configuration). I'm slightly 
>> concerned about the way sub-classes are suposed to handle exceptions:
>> All the abstract method are defined as not throwing exceptions. All 
>> calls to hibernate, however, throw HibernateExceptions. So, for 
>> example, my implementation of getPropertyDirect calls the hibernate 
>> Session.get() method which can throw an exception.
>> Looking at your implementation of the DatabaseConfiguration I can see 
>> that it simply consumes SQLExceptions thrown from the JDBC API, 
>> logging the stack trace. However, what if you want to be warned of 
>> exceptions being thrown by the underlying implementation of 
>> Configuration?
>> I notice you already have a nestable ConfigurationException 
>> implemented. Surely, all Configuration methods should indicate they 
>> will throw this exception if they are expected to read/write data?
>> Also, the AbstractConfiguration class does not describe this contract 
>> (logging all errors throw by underlying framework) or what should be 
>> returned in the event of an error? I assume you should return null 
>> values but this is not described anywhere.
>> Kind regards,
>> -- Ricardo Gladwell

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

View raw message