Streams? There is Stream.onClose.
There are idioms that requires the caller to call close but it does not
cover the case of a caller returning the ExtendedIterator further up the
stack.
AutoCloseable does not solve either.
ExtendedIterator.forEach does this for the run-to-completion case and
run partial case but not if a result is required.
G.getOne* does it by being specific to the operation. For its intended
use, writing out each of the cases was tedious but better than at the
graph access points in the SHACL code.
The best for "with result" I came up with is:
public static <T, X> X
iterRtn( ExtendedIterator<T> iter,
Function<ExtendedIterator<T>, X> action) {
try {
return action.apply(iter);
} finally { iter.close(); }
}
and the loop is needed in the function impl:
ExtendedIterator<String> iter = extended iterator of strings ....
String x = iterRtn(iter, (eIter)->{
while(iter.hasNext()) {
String t = iter.next();
if ( t.equals("B") )
return "Z";
}
return "";
});
None of which are seamless upgrades.
Andy
On 10/03/2021 21:28, Claude Warren wrote:
In the permissions code I have to call close on all the ExtendedIterators
because I have no idea what is behind them.
I tried to add Autoclosable as an interface using a dynamic proxy in the
hopes that all those iterators that extend ExtendedIterator would still
function properly. But there was a conflict between the close methods as
you noted.
I was unable to come up with a solution.
Claude
On Sat, Mar 6, 2021 at 8:33 PM Andy Seaborne <a...@apache.org> wrote:
Could give some details please?
I have tried some things out and they don't give a warning unless close
is explicitly present, unlike InputStream.
Current guess: because ExtendedIterator.close is not the same as
AutoCloseable.close due to throws.
It's a multi-facet area. Is this primarily for exceptions? Early exit of
a loop? Within jena-permissions - obviously you can do what you think is
the right thing.
What about ExtendedIterator.forEach? That closes on exception.
Have you seen the "org.apache.jena.riot.other.G" library which is
functions to work with graphs that do the close thing. That was my
solution to making sure lcose was called. We could move (some of) that
to jena-core.
Is there an interaction with "var"?
Andy
On 06/03/2021 17:56, Claude Warren wrote:
I know that we had discussed adding autoclosable to the iterators but
decided not to. I find that I am doing a lot of try/finally-close
manipulation with extended iterators. Rather than rehashing the previous
discussion (I'll assume we made the correct decision before), I would
like
to suggest an AutoClosableExtendedIterator that extends both
ExtendedIterator and AutoClosable.
Is there a reason not to do this?
Claude
