Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: Cursor to implement Closeable
To: dev@directory.apache.org
References: <56AC7286.2080201@gmail.com>
 <8D5F7E3237B3ED47B84CF187BB17B6661487AF37@SHSMSX103.ccr.corp.intel.com>
 <56AC97CA.6020208@gmail.com>
 <8D5F7E3237B3ED47B84CF187BB17B6661487B312@SHSMSX103.ccr.corp.intel.com>
From: Radovan Semancik <radovan.semancik@evolveum.com>
Message-ID: <56B08321.1000705@evolveum.com>
Date: Tue, 2 Feb 2016 11:21:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
 <8D5F7E3237B3ED47B84CF187BB17B6661487B312@SHSMSX103.ccr.corp.intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 01/30/2016 12:33 PM, Zheng, Kai wrote:
> Not sure if it's a good practice to pass an exception as reason to a close method, as least in Java.
> Confusing: exception thrown when this Cursor is accessed after close. When it's accessed after close, why call the method once more?

Actually (as far as I know) there is no good way to do that in Java. No 
good way at all.

Imagine that you implement a "driver" where LDAP is just one of many 
ways how to access the data. You do LDAP search in the driver and one of 
the entry has an application error. You want to throw an exception that 
indicates that condition, but you also have end the search and close the 
connection. And now imagine that there is a network timeout on close. 
Which exception do you throw?

The typical implementation seems to be throwing the application 
exception and ignoring the IO exceptions from close(). But that may end 
up in resource leakage, because if it is a timeout then the cursor might 
or might not be closed. If the client code does not handle that properly 
then unclosed cursors may stay around for a long time.

On the other hand, throwing the IO exception and ignoring application 
exceptions may be even worse, because it suggests that a retryable 
network error while the root cause of the problem may be non-retryable 
and it may be so serious that re-trying the operation may cause serious 
harm.

So, throwing both exception as nested may in fact be a good compromise.

-- 
Radovan Semancik
Software Architect
evolveum.com