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?
Regards, Kai -----Original Message----- From: Radovan Semancik [mailto:[email protected]] Sent: Tuesday, February 02, 2016 6:21 PM To: [email protected] 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 harm. So, throwing both exception as nested may in fact be a good compromise. -- Radovan Semancik Software Architect evolveum.com
