directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <>
Subject RE: Cursor to implement Closeable
Date Tue, 02 Feb 2016 10:40:21 GMT
Thanks Radovan for the interesting illustration. I guess I understand it but am not so sure.
So application exception is passed to close(exception) method, then in the implementation
of the close method, will it throw the given exception? If it does, how about it timed out?


-----Original Message-----
From: Radovan Semancik [] 
Sent: Tuesday, February 02, 2016 6:21 PM
Subject: Re: Cursor to implement Closeable

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

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

Radovan Semancik
Software Architect

View raw message