commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <>
Subject RE: [configuration] Exception handling - was Automatic reloading
Date Fri, 19 Dec 2003 20:31:38 GMT
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

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!


  -----Original Message-----
  From: Emmanuel Bourg []
  Sent: Friday, December 19, 2003 6:39 PM
  To: Jakarta Commons Developers List
  Subject: Re: [configuration] Exception handling - was Automatic reloading 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

  > 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message