Hi Alex, PAM,
if we are to go away from JNDI, Option 2 is out of question. Anyway, the
backend role is to store data, which has nothing in common with Naming,
isn't it ?
More than that, we may have to build tools on top of this layer,
see no reason to depend on NamingException when we have nothing to do
Option 1 will conflict in some way with JDBM and JE design, as stated by
I would favor Option 3 then.
The good thing is that defining a new set of exceptions is not really
that hard :)
Pierre-Arnaud Marcelot 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. ;)
> On Jan 15, 2008 11:45 PM, Alex Karasulu <email@example.com> <mailto:firstname.lastname@example.org >> 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?