commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Gladwell <ricardo.gladw...@btinternet.com>
Subject Re: [configuration] handling exceptions in AbstractConfiguration implementations
Date Wed, 06 Oct 2004 12:07:55 GMT
Eric Pugh wrote:
> Hi Ricardo..  Sounds like you are working on something I've been wanting for
> a long time!

Of course, I was going to release it anyway so please find the 
source-code attached. Not sure it belongs in commons-configration API; 
probably better contributed to the hibernate project. If you can think 
of any improvements please mail the patches back to me for my own project :)

> In otherwords, say I am using a Configuration object in my code, and I do
> configuration.getDouble("key");.  If getDouble throws an exception then I am
> going to have these try/catch cluases all over the place, cluttering the
> code.  and, I really except getDouble() to allows work.  If it doesn't, my
> application will just pass it on,not have some sort of fancy if getDouble
> fails, then try getString or something weird.

Good point, although I'm still dubious about throwing RuntimeExceptions 
- those things shoot straight through everything like a silver bullet 
and can even crash some servlet engines.

 From my perspective, I'm not bothered if the Configuration object 
throws exceptions: I wouldn't catch such exceptions in my web 
application, instead letting them fly all the way to the exception 
screen. This way, I can see them occuring as I test my application 
through the browser.

Obviously, sometimes when configuring your application you just want 
your configuration to work or keep on working untill if it encounters an 
errors. However, simply allowing your application to ignore exceptions 
until they create new exception elsewhere seems like a good way to 
create hard-to-fix bugs. Surely, it would be better to relay the errors 
and let the application decide what to do with them?

> I think what you can do is just wrap your HibernateException in a
> ConfiguratoinRuntimeException and toss that.  JDBCConfiguration should
> probably be doning the same thing.

Another alternative would be to have a getExceptions() method for all 
Configurations which stores exceptions occuring and stores them for 
later reporting. A good comprimise would be to allow all Configuration 
objects to have two modes: one where exceptions are thrown as soon as 
they occur and another one which stores exceptions as I suggested.

Kind regards,
-- Ricardo Gladwell

>>-----Original Message-----
>>From: Ricardo Gladwell [mailto:ricardo.gladwell@btinternet.com]
>>Sent: Wednesday, October 06, 2004 12:56 PM
>>To: Jakarta Commons Developers List
>>Subject: [configuration] handling exceptions in AbstractConfiguration
>>implementations
>>
>>
>>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

Mime
View raw message