Hi Pam, I was thinking exactly along the same lines here especiaally since JE's DatabaseException does not extend IOException. BTW this is funny but note that I already refactored from NamingException to IOException but just now felt I was doing something stupid.
Thanks for your comments, Alex On Jan 16, 2008 3:20 AM, Pierre-Arnaud Marcelot <[EMAIL PROTECTED]> wrote: > Hi Alex, > > Option 1 seems the easiest solution but will it work with an exception > based on DatabaseException ? > I don't think... Reading the JE API, DatabaseException extends Exception > and not IOException. > > I like Option 3 and the idea to encapsulate the exception thrown inside > our "own exception". But it means surely a lot of refactoring... > > My 2 cents. ;) > > Pierre-Arnaud > > > On Jan 15, 2008 11: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 > > > > > > > > >
