directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: About exceptions
Date Sun, 14 Mar 2010 10:42:14 GMT
On Sun, Mar 14, 2010 at 10:23 AM, Stefan Seelmann <> wrote:
> Emmanuel Lecharny wrote:
>> Hi,
>> it's about time to talk about exceptions, as many methods will throw an
>> exception, and it would be good to know what to throw !
>> We should first have a base exception, and I suggest using
>> LdapException. Evey other exception will inherit this one.
>> The second point is that the LDAP protocol define a list of errors, and
>> we should map an exception to those errors. This has been done for JNDI,
>> and it's a pretty good idea to keep our exception hierarchy close to the
>> JNDI one.
>> AFAICT, neither OpenDS nor Unboundid define an exception hierarchy.
>> Something I don't find useful is a method throwing a
>> NullPointerException (IMO, this is totally useless, and certainly not an
>> exception you want to add in the list of thrown exceptions for a method
>> ...).
>> jLDAP defines a few exceptions, with a base LDAPException class.
>> LDAPReferralException, LDAPLocalException are subclasses and used for
>> some specific needs.
>> All in all, JNDI's exception system is pretty decent, and I think we
>> should mimic it, but without implementing or extending the JNDI classes
>> (something ADS is doing, and it collides with the renaming of DN, as
>> it's not anymore a NAME extension).
>> thoughts ?
> I agree that a exception hierarchy with a base LdapExcepton class makes
> sense.
> One important thing is to add the result code to the exception. In JNDI
> you have to extract it from the exception message.
> Another thing I don't like with JNDI is the handling of referrals and
> search continuations. I think for referrals it makes sense to throw an
> exception. But for search continuations we shouldn't throw an exception
> but a SearchResultReference object should be returned.


I also think the ability to pursue references should be a very easy
task for the coder. Chaining should be a construct built in and really
intuitive.  Don't know however how this can best be designed from the
API perspective.

> I also wonder if we need to generate an exception for all the result
> messages. For example for an timeLimitExceeded or sizeLimitExceeded or
> adminLimitExceeded result I think it is not necessary, the user can just
> check the result code if s/he wants to handle that case.

I think the exception or perhaps a callback mechanism might be needed
here to cleanup or respond to these kinds of cases.  It's just a
matter of interrupting the flow so detection and handling can proceed.
We still need some kind of trigger to let the user know the time limit
for example has been exceeded.  Otherwise all code including the main
non-exceptional pathways will be cluttered with checks for these

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::

View raw message