directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: About exceptions
Date Sun, 14 Mar 2010 13:18:25 GMT
On 3/14/10 11:42 AM, Alex Karasulu wrote:
> 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.
> +1
> 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.
Yeah, this has to be handled on the API side. Still have to think about it.
>> 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
> cases.
I agree. Having to add try/catch to handle time ans size limit exception 
would be a real PITA. In any case, the last response will contain the 
resultCode, so I'm not sure that we shoud throw an exception in this case.

To be discussed further...

Emmanuel L├ęcharny

View raw message