Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 11139 invoked from network); 16 Jan 2008 16:40:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Jan 2008 16:40:21 -0000 Received: (qmail 82270 invoked by uid 500); 16 Jan 2008 16:40:11 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 82230 invoked by uid 500); 16 Jan 2008 16:40:11 -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 82219 invoked by uid 99); 16 Jan 2008 16:40:11 -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 08:40:11 -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 chris.custine@gmail.com designates 64.233.162.238 as permitted sender) Received: from [64.233.162.238] (HELO nz-out-0506.google.com) (64.233.162.238) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jan 2008 16:39:46 +0000 Received: by nz-out-0506.google.com with SMTP id o1so225374nzf.10 for ; Wed, 16 Jan 2008 08:39:51 -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=Z5Hygri/AEjs//IKbJgbAALv2WvYydMnWxCdvgF6Pcw=; b=RaSv7zsFRnPcyyifAksVz4HsvUYR1Uu4BrYjG4wAptPydXvdyrSF7YEUVv0nZz/KDMZT2QxXjWNzwGBivSZNXTgP1NL4ReR+5a/Tvd7HWzJ1FWwWU/hxebPFXDzJehwvBrBj32ajI1lHDM6V4WArqJ3p3POkB316QYaT/PEwRvM= 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=s2oV1HdSC7dQdwNu4Q7/R7/vRYFV0TiPLnwzRx3YUeKE8uJpiyp+gL8lgOm6xfXaCwE5j8tMJwV3j0KA18P5TrLqUxwy8NlmTb/q9RD5fVq2WMDyhwojgJzf3fs/rZMsAr3t0864ziE4AOIm+xHcyvjnJ9Wjh2wATmCz/6aK87Q= Received: by 10.141.36.10 with SMTP id o10mr687144rvj.176.1200501590858; Wed, 16 Jan 2008 08:39:50 -0800 (PST) Received: by 10.141.202.11 with HTTP; Wed, 16 Jan 2008 08:39:50 -0800 (PST) Message-ID: <43b026c70801160839x57448b3aoe351461622b1464b@mail.gmail.com> Date: Wed, 16 Jan 2008 09:39:50 -0700 From: "Chris Custine" Sender: chris.custine@gmail.com To: "Apache Directory Developers List" Subject: Re: [ApacheDS] Partition design and interfaces In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13688_19630181.1200501590829" References: X-Google-Sender-Auth: 06db920a4105669b X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_13688_19630181.1200501590829 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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_13688_19630181.1200501590829 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 <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_13688_19630181.1200501590829--