commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Inger, Matthew" <>
Subject RE: [configuration] Exception handling - was Automatic reloading
Date Fri, 19 Dec 2003 14:49:35 GMT
In general, it's my opinion that one should never
throw, catch, or declare thrown the classes Throwable
and Exception.  The only exception is at the top level
of your code (say your servlet), which should capture
any non handled errors, and display a system error page.

Wrapper exceptions as suggested is the general approach
i've always used, and I see used all over the place.  For the
situation mentioned below, i would personally create a
ConfigurationException and a subclass ConfigurationIOException
that way someone could catch the specific exception type if
they wanted to.  You could then declare all your methods to
throw ConfigurationException to avoid signature changes in the

-----Original Message-----
From: Oliver Heger []
Sent: Friday, December 19, 2003 4:53 AM
To: Jakarta Commons Developers List
Subject: [configuration] Exception handling - was Automatic reloading


;-) thank you for putting my name in the author field of 
ReloadingStrategy, but I do not deserve this honour. This is all your 

I have one remark and this is not specific to your code, but applies to 
whole configuration: Our exception handling is very inconsistent in some 
points. For instance, in the new PersistentConfiguration interface the 
save() method throws an IOException and the load() method throws an 
Exception. I know, this is because the underlying methods you want to 
call have these throws clauses. So I would suggest to make this more 

There are some methods that have a throws Exception clause, which is 
quite ugly in my opinion. Well, some of them can indeed throw a bunch of 
different exception types. What could we do to improve this? How about 
introducing a ConfigurationException class, which can have a nested 

What do others think about this? This is a kind of cleanup, which maybe 
should be done before the first release. Later it could be more 
problematic because of compatibility issues.


Emmanuel Bourg schrieb:

> I have implemented the reloading strategy suggested by Oliver. I 
> introduced a PersistentConfiguration interface defining the load() and 
> save() methods, the ReloadableConfiguration decorator only accepts 
> instances of PersistenConfiguration. Also I fixed the missing clear() 
> method in the HierarchicalConfiguration class and moved the reloading 
> stuff in a specific sub package.
> I haven't implemented all the strategies mentioned in my previous mail 
> yet. I think we might make the URLChangedReloadingStrategy to work on 
> configurations embedded in a jar or zip file as well, this should be 
> easy to implement with the JarFile/JarEntry  obtained from the URL 
> through a JarURLConnection.
> Emmanuel Bourg

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

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

View raw message