Just one clarification below:

On Jan 16, 2008 10:00 AM, Alex Karasulu <akarasulu@apache.org> wrote:
Hi Ersin,

Glad to see you're lurking ...

On Jan 16, 2008 8:38 AM, Ersin Er <ersin.er@gmail.com> wrote:

I think Spring approach is here is nice. They have their own unchecked
exception hierarchy and adapters for different data stores convert
specific exceptions to one of the exceptions in Spring's hierarchy.

This is a very interesting idea.  I'm just wondering what impact this would have on higher levels wrt exception handling.  If using unchecked exceptions are the preferred way then why would anyone bother having their API throw checked exceptions?
can define a simple LDAP related data store exception hierarchy and
expect all partition implementations to obey it.

I guess by making all exceptions unchecked it makes exception raising and handling by API interface implementors and implementation users to be based on a looser contract.

What I mean by looser contract is that the requirements of the contract if violated some way must be handled not at compile time (development/creation time) but at runtime.  And this may never happen at runtime even if the exception is potentially recoverable.  The option exists to ignore exceptional conditions all together or to just pay attention to just those that concern the user.  This is riskier if something goes wrong however the option is left to the coder and not required of him.  This is looser in my mind and gives more freedom to the user of the API while potentially allowing the user to shoot themselves in the foot.