You are viewing a plain text version of this content. The canonical link for it is here.
Posted to api@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/03/12 12:05:08 UTC
About exceptions
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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: About exceptions
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 3/14/10 11:42 AM, Alex Karasulu wrote:
> On Sun, Mar 14, 2010 at 10:23 AM, Stefan Seelmann<se...@apache.org> 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...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: About exceptions
Posted by Alex Karasulu <ak...@gmail.com>.
On Sun, Mar 14, 2010 at 10:23 AM, Stefan Seelmann <se...@apache.org> 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.
> 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.
Regards,
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: About exceptions
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 3/14/10 10:56 AM, Kiran Ayyagari wrote:
>
> from the recent experience of migrating test cases to client-api
> have observed that unlike jndi we return result codes and I liked this
> (the jndi exceptions rather give me a feeling like 'use exceptions for
> control flow', which is considered as a bad practice by many)
>
> so +1 for returning result codes instead of exceptions
Yes, that's pretty obvious we should do that.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: About exceptions
Posted by Kiran Ayyagari <ay...@gmail.com>.
>> 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.
+1 too
>
> 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.
from the recent experience of migrating test cases to client-api
have observed that unlike jndi we return result codes and I liked this
(the jndi exceptions rather give me a feeling like 'use exceptions for
control flow', which is considered as a bad practice by many)
so +1 for returning result codes instead of exceptions
Kiran Ayyagari
Re: About exceptions
Posted by Stefan Seelmann <se...@apache.org>.
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