Weird IndexWriter.close() usage [LUCENE-4760]

I'm using IndexWriter on such a way that it can be interrupted, since the streams i'm using to output to file can be interrupted. So far so good, but what i'm finding strange is the (only) way i've found to prevent the file lock being held afterwards.

Normally i'd do a try / catch / finally block where the finally would close() and handle exceptions from the close. However, IndexWriter "close()" is more like a buffered commit, where many exceptions can occur, so i left it on the main part of the code.

try{... index.close(); } catch { /**log**/ } finally {
if (IndexWriter.isLocked(cacheDir)) {
IndexWriter.unlock(cacheDir);
}
}

Didn't work. The lock couldn't be unlocked (always) if the stream was interrupted

So in desperation, i tried to be more literal in my interpretation of the IndexWriter.close() javadoc and tried
try {
...
indexWriter.close();
} catch (IOException ex) {
try {
indexWriter.close();
} finally {
if (IndexWriter.isLocked(cacheDir)) {
IndexWriter.unlock(cacheDir);
}
}
throw ex;
} finally {
...
}

This worked (the lock was always released if a additional close() was invoked in a situation where the lock would be held before trying to unlock it), but i find it really counter-intuitive, and would wish for at least additional javadoc attention, or a redesign on a major API revision.

---
Migrated from [LUCENE-4760](https://issues.apache.org/jira/browse/LUCENE-4760) by i30817, updated Feb 08 2013

Start by reading the IndexWriter.close() and lock-handling behavior described in the issue, then reproduce the interrupted-stream case. Determine whether the intended fix is clearer javadoc, a behavioral change, or an API redesign; the issue is complete only when the post-close lock behavior and exception handling are unambiguous and covered by the project’s tests.

Written by the indexing model from the issue text.