Remove even more boolean success flags

[thecoop]

Most of the remaining ones are in backwards-compatible codecs and the test framework

[thecoop]

Exceptions thrown by this should be handled by the method calling this close() method

[thecoop]

The new code implicitly calls close() on writer after rollback() has been called, but IndexWriter can handle that

[uschindler]

This one is more complicated than the others. Especially the first file is hard. Why was it possible to remove success without any other code change?

[thecoop]

You mean SortingStrategy? sortedFile was being closed in all situations anyway, but this change makes it throw any exceptions regardless. This is ok because this is only used in hunspell.Dictionary, which iterates through the EntrySorter here.

That loop only exits normally once it gets to the end (returns null), all other possible exits of that loop are through exceptions. The exception will bubble up to the caller, where the try block will call EntrySorter.close. If that throws an exception (which it didn't previously), it'll be added as suppressed to the original exception, so the original behaviour is maintained. The only difference is that an exception while closing the file will be added as suppressed, rather than being thrown away completely.

[github-actions]

This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the dev@lucene.apache.org list. Thank you for your contribution!

[uschindler]

This is really a hard one. The easy ones are perfectly fine, the other ones are partly hard to read, biut with github side-by-side view its manageable:

• Simple ones are fine
• SegmentCoreReaders is more complex than before (nested try blocks). Maybe revert that one and keep the old success pattern here?
• FreeTextSuggester is not understandable by me :-(
• TestSimpleServer is fine, but you need to notice the try (socket) on top!

[thecoop]

It helps to note here that reader and dir are closed whatever the outcome. This means that both those can be moved to try-with-resources when they are created, so they are always closed.

Previously, writer was only closed explicitly if an exception was thrown. If it completed normally, only rollback() was called. But IndexWriter checks for close being called after rollback, and makes sure that it is only closed once. So this means that writer can also be in a try-with-resources when it is created, as the extra implicit close at the end of the outer try is a no-op if rollback is called, and closes it if an exception is thrown (which is what the previous code also did).

In terms of live-ness, the try for the finally block the IOUtils.rm runs in has increased in scope to include creating the Document, FieldType, and IndexWriter at the start. Previously, if IndexWriter threw an exception, the directory wouldn't be cleaned up. This is now the case, so it won't leak tempIndexPath if IndexWriter throws an exception