Re: [configuration] Exception handling - was Automatic reloadingI would like to move on a 1.0 very aggressively now that the vote has passed. Part of me feels that we should basically take the code as is and make that be 1.0. It is very well tested, stable, and in use in some projects. By cutting a 1.0, then we can take our time thinking about the best way to extend configuration. Right now there seem to be a couple ideas floating about:
1) Reloadable Configurations. Change a configuration from a static to a dynamic set of data. This may drag along ideas like a reloading strategy etc.. 2) Extend getters.. Add more different types of gets.. 3) Better Exception handling. The more sophisticated Configuration gets, the more types of exceptions we need to deal with. By having a 1.0 out of the way, we can start on 1.1 which might include work in these three areas without feeling pressure to jam something out quick just to get it in pre 1.0. I would rather release often and have the API change then stall until we are happy with everything in the API! Comments? Eric -----Original Message----- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Friday, December 19, 2003 6:39 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Exception handling - was Automatic reloading [EMAIL PROTECTED] wrote: > 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. That was your idea ;) > 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. Indeed, I started with the load() and save() methods throwing an IOException, then I changed to an Exception on load() to be compatible with the DOM4JConfiguration.load() method throwing a DOM4JException. > 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? I agree, that's a common practice. If a persistent configuration was stored into a database we would get a SQLException on load() & save(), so we need a generic exception abstracting the implementation exceptions. A ConfigurationException is a better choice than a simple 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. Is there a 1.0 release planned soon after the promotion of [configuration] to Commons Proper ? Emmanuel Bourg
