directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [Shared] Cursor interface Excpetions
Date Sun, 06 Jun 2010 09:31:17 GMT
On 6/6/10 10:48 AM, Alex Karasulu wrote:
> On Sat, Jun 5, 2010 at 11:31 PM, Stefan Seelmann<seelmann@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



Mime
View raw message