directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <seelm...@apache.org>
Subject Re: About exceptions
Date Sun, 14 Mar 2010 08:23:42 GMT
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 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.

Kind Regards,
Stefan


Mime
View raw message