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 future. -----Original Message----- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Friday, December 19, 2003 4:53 AM To: Jakarta Commons Developers List Subject: [configuration] Exception handling - was Automatic reloading 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
