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, and I
see no reason to depend on NamingException when we have nothing to do
with LDAP.
Option 1 will conflict in some way with JDBM and JE design, as stated by
PAM.
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. ;)
Pierre-Arnaud
On Jan 15, 2008 11:45 PM, Alex Karasulu <[EMAIL PROTECTED]
<mailto:[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
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
