From dev-return-23251-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed Jan 16 14:32:56 2008 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 75907 invoked from network); 16 Jan 2008 14:32:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Jan 2008 14:32:56 -0000 Received: (qmail 34043 invoked by uid 500); 16 Jan 2008 14:32:45 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 33986 invoked by uid 500); 16 Jan 2008 14:32:45 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 33974 invoked by uid 99); 16 Jan 2008 14:32:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jan 2008 06:32:45 -0800 X-ASF-Spam-Status: No, hits=2.4 required=10.0 tests=HTML_MESSAGE,SPF_PASS,SUBJECT_FUZZY_TION X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.146.178 as permitted sender) Received: from [209.85.146.178] (HELO wa-out-1112.google.com) (209.85.146.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jan 2008 14:32:20 +0000 Received: by wa-out-1112.google.com with SMTP id m38so506982waf.5 for ; Wed, 16 Jan 2008 06:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=RC5KXU5tXDNJyRg6U1BsRhDWkc9jMecX5K8c1De22Ps=; b=XeSyc9wsGfZFH/j4lXGBJukq9QMIo6MG+wGyVwUvaWaXAxWqbyw5N956hFC6CBkHr3osyqw94/Pul4jdXk4p5eD7ILr0Azy7mw+p9wTkWvspm170h6j7ZgOY8RAC0m1VDz10J7Cc/LcnyfhT8VE6Rhahx5n0ZpzobJdD+FBE1BY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=gS8K342TIbZZOxifLRWlIDL1gWB8ZFqLKoOH6BcnNr0qiWhjT9SmTpu+z29OavhpWJeu8OW3/lMYYWXj5tMnfdL5Xqfh6inyjOZ3hiVb04tnz2cHvr4xM/9DEvexzBEBPnMEBAkHOsIRhxdAJdtkUZn1VrNPJCiRM3tXMPAorVo= Received: by 10.114.15.1 with SMTP id 1mr998567wao.27.1200493946622; Wed, 16 Jan 2008 06:32:26 -0800 (PST) Received: by 10.115.18.12 with HTTP; Wed, 16 Jan 2008 06:32:26 -0800 (PST) Message-ID: Date: Wed, 16 Jan 2008 09:32:26 -0500 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" Subject: Re: [ApacheDS] Partition design and interfaces In-Reply-To: <98d8c0860801160020s190105d4se850d557363da410@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_24997_29515914.1200493946620" References: <98d8c0860801160020s190105d4se850d557363da410@mail.gmail.com> X-Google-Sender-Auth: a6b5b0997f9f2850 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_24997_29515914.1200493946620 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 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 > > > > > > > > > ------=_Part_24997_29515914.1200493946620 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 <pa@marcelot.net> 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 <akarasulu@apache.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?

Alex

 



------=_Part_24997_29515914.1200493946620--