[configuration] Exception handling - was Automatic reloading

[Oliver Heger <he...@med.uni-marburg.de>]

Emmanuel,

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

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

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 
exception?

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.

Oli

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