No, I haven't meant current Directory API implementation. That seems to
be yet another approach. And I must confess that it still is not
entirely clear to me.
What I was describing is a way how this is usually done in Java world in
general. Just to illustrate that there is no good standard solution for
this (as far as I know).
Ad current API implementation: Personally, I also do NOT entirely like
the close(Exception) that just passes the exception to the monitor. But
I see it as an utility method which is not directly interfering with
Closeable, so changing it or removing it right now is perhaps not that
important.
We should perhaps discuss the overall error handling approach first.
--
Radovan Semancik
Software Architect
evolveum.com
On 02/02/2016 11:40 AM, Zheng, Kai wrote:
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
