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. Thanks, Alex On Jan 16, 2008 11:39 AM, Chris Custine <[EMAIL PROTECTED]> wrote: > 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. > > Chris > > > On Jan 15, 2008 3:45 PM, Alex Karasulu <[EMAIL PROTECTED]> 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? > > > > Alex > > > > > > > > >
