Thanks Chris for your commentary. I'm starting to feel more and more confident that option 3 is the way to go. Both you and Ersin seemed to say that although somewhat advantageous using a runtime exception for the base class is not as necessary in our case. I think you're right in that the user of this API is predominately the server since this is the server->partition interface.
I will go ahead and change things to use option 3 now with checked exceptions.
I really like the idea of an exception hierarchy specific to partitions (the root cause from the underlying data store would always be made available anyway). Like Ersin mentions, Spring does something similar with their DAO abstraction on top of Hibernate, JDBC, etc. and I think it works really well, but I do think checked exceptions are more pertinent in our use case.
I support option 3.
ChrisOn Jan 15, 2008 3:45 PM, Alex Karasulu < email@example.com> wrote:Hi all,
Different underlying stores have different kinds of checked exceptions they throw at the lowest level. For example JDBM is humble and just uses IO exceptions. The JE authors use an exception hierarchy based on DatabaseException. I was wondering if there was a preference out the base class for what exceptions are thrown from partitions? Right now there are a few options:
(1) Throw exceptions that extend IOException (works well with JDBM)
(2) Throw NamingExceptions works well with Java Naming but we have a bad taste in our mouths from this.
(3) Create our own base class for exceptions thrown at these lower layers like say PartitionException
Right now I went with IOException but I'm thinking it might be biased towards a particular partition implementation. Does anyone have some opinion one way or the other?