You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Felix Knecht <fe...@otego.com> on 2010/06/05 11:57:54 UTC
[Shared] Cursor interface Excpetions
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Cursor interface [1] throws almost for each method an 'Exception'. I
suggest to make this less generic and throw either the (from javadoc)
"UnsupportedOperationException" or in analogy to the Iterator a
"NoSuchElementException" for methods like before,after,last,first, ...
WDYT?
[1]
http://people.apache.org/~felixk/shared-docs/xref/org/apache/directory/shared/ldap/cursor/Cursor.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwKH6IACgkQ2lZVCB08qHFQAACeO1snM9Hb0hp9CzX9bJVerSZa
oQUAoKno/CKWngureFXd8+AaYtMu1lWg
=qqpa
-----END PGP SIGNATURE-----
Re: [Shared] Cursor interface Excpetions
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 6/6/10 10:48 AM, Alex Karasulu wrote:
> On Sat, Jun 5, 2010 at 11:31 PM, Stefan Seelmann<se...@apache.org>wrote:
>
>
>> Emmanuel Lecharny schrieb:
>>
>>> On 6/5/10 12:18 PM, Felix Knecht wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 06/05/10 12:02, Emmanuel Lecharny wrote:
>>>>
>>>>
>>>>> On 6/5/10 11:57 AM, Felix Knecht wrote:
>>>>>
>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> The Cursor interface [1] throws almost for each method an
>>>>>> 'Exception'. I
>>>>>> suggest to make this less generic and throw either the (from javadoc)
>>>>>> "UnsupportedOperationException" or in analogy to the Iterator a
>>>>>> "NoSuchElementException" for methods like before,after,last,first, ...
>>>>>>
>>>>>>
>>>>>>
>>>>> I saw that while I was propagating the LdapException through the
>>>>>
>> server.
>>
>>>>> IMO, we should define a base CursorException class, and derive some
>>>>>
>> more
>>
>>>>> specific exception like the one you suggest.
>>>>>
>>>>>
>>>> What would be the benefit of the Exception inflation instead of using
>>>> already existing ones where it logically makes sense?
>>>>
>>>>
>>> The idea is to use the best Exception for each error case. If the
>>> existing exceptions fit, then I think we can avoid defining our own tree
>>> of exceptions. But I doubt we can cover all the cases with those
>>> existing exception.
>>>
>>>
>>> As I'm not a specialist of the Store code, maybe Alex or Stefan can
>>> bring a bit more light on this aspect.
>>>
>>
>> The org.apache.directory.shared.ldap.cursor package already defines
>> three exceptions, all extend "Exception":
>> - InvalidCursorPositionException
>> - InconsistentCursorStateException
>> - CursorClosedException
>>
>> The InvalidCursorPositionException is thrown when calling Cursor.get()
>> but the cursor isn't positioned correctly. An option is to use a
>> NoSuchElementException instead.
>>
>> The InconsistentCursorStateException is never used.
>>
>> The CursorClosedException is thrown when Cursor.close() was called and
>> afterwards another cursor method is called. An option is to use an
>> IllegalStateException instead.
>>
>> Other exceptions are thrown by the underlying data stores if there are
>> problems when getting data from an index table for example. I think most
>> of them are IOExceptions. Here it makes sense to define a custom
>> exception to wrap those guys.
>>
>> The question is (and I think I can remember we already had such a
>> discussion): should we use checked or unchecked exceptions?
>>
>> If we use checked exceptions it makes sense to define a base
>> CursorException and to derive the above mention exceptions from it.
>>
>> If we use unchecked exceptions we should reuse the existing
>> IllegalStateException and NoSuchElementException.
>>
>>
>>
> I think this is a matter of how early we want to check/handle various issues
> with a Cursors operation. If we want checks/handling to occur early where
> the error occurs in the code using the Cursor then checked exceptions are
> best. IMO I think this might be best.
>
> On the other hand if it's OK to handle unchecked exceptions higher up in the
> execution stack then let's go with unchecked. This however brings the need
> to handle Cursor failures higher up outside of where the Cursor is used and
> we loose some focus and possibly handle exceptions for the Cursor in regions
> where it is less coherent.
>
> +1 on checked exceptions.
>
+1 too.
/The Java Programming Language/, by Gosling, Arnold, and Holmes :
"Unchecked runtime exceptions represent conditions that, generally
speaking, reflect errors in your program's logic and cannot be
reasonably recovered from at run time."
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: [Shared] Cursor interface Excpetions
Posted by Alex Karasulu <ak...@apache.org>.
On Sat, Jun 5, 2010 at 11:31 PM, Stefan Seelmann <se...@apache.org>wrote:
> Emmanuel Lecharny schrieb:
> > On 6/5/10 12:18 PM, Felix Knecht wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 06/05/10 12:02, Emmanuel Lecharny wrote:
> >>
> >>> On 6/5/10 11:57 AM, Felix Knecht wrote:
> >>>
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> The Cursor interface [1] throws almost for each method an
> >>>> 'Exception'. I
> >>>> suggest to make this less generic and throw either the (from javadoc)
> >>>> "UnsupportedOperationException" or in analogy to the Iterator a
> >>>> "NoSuchElementException" for methods like before,after,last,first, ...
> >>>>
> >>>>
> >>> I saw that while I was propagating the LdapException through the
> server.
> >>>
> >>> IMO, we should define a base CursorException class, and derive some
> more
> >>> specific exception like the one you suggest.
> >>>
> >> What would be the benefit of the Exception inflation instead of using
> >> already existing ones where it logically makes sense?
> >>
> > The idea is to use the best Exception for each error case. If the
> > existing exceptions fit, then I think we can avoid defining our own tree
> > of exceptions. But I doubt we can cover all the cases with those
> > existing exception.
> >
> >
> > As I'm not a specialist of the Store code, maybe Alex or Stefan can
> > bring a bit more light on this aspect.
>
>
> The org.apache.directory.shared.ldap.cursor package already defines
> three exceptions, all extend "Exception":
> - InvalidCursorPositionException
> - InconsistentCursorStateException
> - CursorClosedException
>
> The InvalidCursorPositionException is thrown when calling Cursor.get()
> but the cursor isn't positioned correctly. An option is to use a
> NoSuchElementException instead.
>
> The InconsistentCursorStateException is never used.
>
> The CursorClosedException is thrown when Cursor.close() was called and
> afterwards another cursor method is called. An option is to use an
> IllegalStateException instead.
>
> Other exceptions are thrown by the underlying data stores if there are
> problems when getting data from an index table for example. I think most
> of them are IOExceptions. Here it makes sense to define a custom
> exception to wrap those guys.
>
> The question is (and I think I can remember we already had such a
> discussion): should we use checked or unchecked exceptions?
>
> If we use checked exceptions it makes sense to define a base
> CursorException and to derive the above mention exceptions from it.
>
> If we use unchecked exceptions we should reuse the existing
> IllegalStateException and NoSuchElementException.
>
>
I think this is a matter of how early we want to check/handle various issues
with a Cursors operation. If we want checks/handling to occur early where
the error occurs in the code using the Cursor then checked exceptions are
best. IMO I think this might be best.
On the other hand if it's OK to handle unchecked exceptions higher up in the
execution stack then let's go with unchecked. This however brings the need
to handle Cursor failures higher up outside of where the Cursor is used and
we loose some focus and possibly handle exceptions for the Cursor in regions
where it is less coherent.
+1 on checked exceptions.
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [Shared] Cursor interface Excpetions
Posted by Stefan Seelmann <se...@apache.org>.
Emmanuel Lecharny schrieb:
> On 6/5/10 12:18 PM, Felix Knecht wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 06/05/10 12:02, Emmanuel Lecharny wrote:
>>
>>> On 6/5/10 11:57 AM, Felix Knecht wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> The Cursor interface [1] throws almost for each method an
>>>> 'Exception'. I
>>>> suggest to make this less generic and throw either the (from javadoc)
>>>> "UnsupportedOperationException" or in analogy to the Iterator a
>>>> "NoSuchElementException" for methods like before,after,last,first, ...
>>>>
>>>>
>>> I saw that while I was propagating the LdapException through the server.
>>>
>>> IMO, we should define a base CursorException class, and derive some more
>>> specific exception like the one you suggest.
>>>
>> What would be the benefit of the Exception inflation instead of using
>> already existing ones where it logically makes sense?
>>
> The idea is to use the best Exception for each error case. If the
> existing exceptions fit, then I think we can avoid defining our own tree
> of exceptions. But I doubt we can cover all the cases with those
> existing exception.
>
>
> As I'm not a specialist of the Store code, maybe Alex or Stefan can
> bring a bit more light on this aspect.
The org.apache.directory.shared.ldap.cursor package already defines
three exceptions, all extend "Exception":
- InvalidCursorPositionException
- InconsistentCursorStateException
- CursorClosedException
The InvalidCursorPositionException is thrown when calling Cursor.get()
but the cursor isn't positioned correctly. An option is to use a
NoSuchElementException instead.
The InconsistentCursorStateException is never used.
The CursorClosedException is thrown when Cursor.close() was called and
afterwards another cursor method is called. An option is to use an
IllegalStateException instead.
Other exceptions are thrown by the underlying data stores if there are
problems when getting data from an index table for example. I think most
of them are IOExceptions. Here it makes sense to define a custom
exception to wrap those guys.
The question is (and I think I can remember we already had such a
discussion): should we use checked or unchecked exceptions?
If we use checked exceptions it makes sense to define a base
CursorException and to derive the above mention exceptions from it.
If we use unchecked exceptions we should reuse the existing
IllegalStateException and NoSuchElementException.
wdyt?
Kind Regards,
Stefan
Re: [Shared] Cursor interface Excpetions
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 6/5/10 12:18 PM, Felix Knecht wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/05/10 12:02, Emmanuel Lecharny wrote:
>
>> On 6/5/10 11:57 AM, Felix Knecht wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> The Cursor interface [1] throws almost for each method an 'Exception'. I
>>> suggest to make this less generic and throw either the (from javadoc)
>>> "UnsupportedOperationException" or in analogy to the Iterator a
>>> "NoSuchElementException" for methods like before,after,last,first, ...
>>>
>>>
>> I saw that while I was propagating the LdapException through the server.
>>
>> IMO, we should define a base CursorException class, and derive some more
>> specific exception like the one you suggest.
>>
> What would be the benefit of the Exception inflation instead of using
> already existing ones where it logically makes sense?
>
The idea is to use the best Exception for each error case. If the
existing exceptions fit, then I think we can avoid defining our own tree
of exceptions. But I doubt we can cover all the cases with those
existing exception.
As I'm not a specialist of the Store code, maybe Alex or Stefan can
bring a bit more light on this aspect.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: [Shared] Cursor interface Excpetions
Posted by Felix Knecht <fe...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/05/10 12:02, Emmanuel Lecharny wrote:
> On 6/5/10 11:57 AM, Felix Knecht wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> The Cursor interface [1] throws almost for each method an 'Exception'. I
>> suggest to make this less generic and throw either the (from javadoc)
>> "UnsupportedOperationException" or in analogy to the Iterator a
>> "NoSuchElementException" for methods like before,after,last,first, ...
>>
>
> I saw that while I was propagating the LdapException through the server.
>
> IMO, we should define a base CursorException class, and derive some more
> specific exception like the one you suggest.
What would be the benefit of the Exception inflation instead of using
already existing ones where it logically makes sense?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwKJFgACgkQ2lZVCB08qHFQgACgjaFHOCO4jOWEXUyq4a2ZCXvP
tO8An07xdjFYoC628N38O3puiIWSyfGy
=MYJd
-----END PGP SIGNATURE-----
Re: [Shared] Cursor interface Excpetions
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 6/5/10 11:57 AM, Felix Knecht wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The Cursor interface [1] throws almost for each method an 'Exception'. I
> suggest to make this less generic and throw either the (from javadoc)
> "UnsupportedOperationException" or in analogy to the Iterator a
> "NoSuchElementException" for methods like before,after,last,first, ...
>
I saw that while I was propagating the LdapException through the server.
IMO, we should define a base CursorException class, and derive some more
specific exception like the one you suggest.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com