Hi Ricardo.. Sounds like you are working on something I've been wanting for
a long time! At any rate.. I believe there is a
ConfigurationRuntimeException that you could throw, even though it's not
part of the API.
I think the reason that most of the gets don't throw an exception is because
99% of the time if you throw an exception then the calling class will just
have to rethrow it.
In otherwords, say I am using a Configuration object in my code, and I do
configuration.getDouble("key");. If getDouble throws an exception then I am
going to have these try/catch cluases all over the place, cluttering the
code. and, I really except getDouble() to allows work. If it doesn't, my
application will just pass it on,not have some sort of fancy if getDouble
fails, then try getString or something weird.
I think what you can do is just wrap your HibernateException in a
ConfiguratoinRuntimeException and toss that. JDBCConfiguration should
probably be doning the same thing.
Eric
> -----Original Message-----
> From: Ricardo Gladwell [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 06, 2004 12:56 PM
> To: Jakarta Commons Developers List
> Subject: [configuration] handling exceptions in AbstractConfiguration
> implementations
>
>
> Hi All,
>
> I'm currently developing a sub-class of the AbstractConfiguration
> classthat uses Hibernate to access configuration properties
> (unimaginatively called Hibernate Configuration). I'm slightly concerned
> about the way sub-classes are suposed to handle exceptions:
>
> All the abstract method are defined as not throwing exceptions. All
> calls to hibernate, however, throw HibernateExceptions. So, for example,
> my implementation of getPropertyDirect calls the hibernate Session.get()
> method which can throw an exception.
>
> Looking at your implementation of the DatabaseConfiguration I can see
> that it simply consumes SQLExceptions thrown from the JDBC API, logging
> the stack trace. However, what if you want to be warned of exceptions
> being thrown by the underlying implementation of Configuration?
>
> I notice you already have a nestable ConfigurationException implemented.
> Surely, all Configuration methods should indicate they will throw this
> exception if they are expected to read/write data?
>
> Also, the AbstractConfiguration class does not describe this contract
> (logging all errors throw by underlying framework) or what should be
> returned in the event of an error? I assume you should return null
> values but this is not described anywhere.
>
> Kind regards,
> -- Ricardo Gladwell
>
> ---------------------------------------------------------------------
> 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]
