Michael Gibney created SOLR-16163:
-------------------------------------
Summary: Review unintended try-with-resources closing-order
modifications
Key: SOLR-16163
URL: https://issues.apache.org/jira/browse/SOLR-16163
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: main (10.0)
Reporter: Michael Gibney
In migrating from "init/try/close-in-finally" to "try-with-resources" closing
(e.g., for {{SolrCore.close()}}), it is possible to subtly change the order of
execution.
Consider the case where:
{code}
Closeable c = initCloseable();
try {
doSomeStuff(c);
} finally {
doSomeCleanup();
c.close();
}
{code}
is replaced by:
{code}
try (Closeable c = initCloseable()) {
doSomeStuff(c);
} finally {
doSomeCleanup();
}
{code}
This change has the effect of changing the order of execution; in the
try-with-resources variant, c.close() will be called _before_ doSomeCleanup().
In cases where there is no ordering requirement there's probably no harm in
this, but in some cases this can be problematic. See [PR
#815|https://github.com/apache/solr/pull/815].
To make matters worse, it seems that the issues that can be introduced by this
kind of thing do not reproduce reliably, and seem to throw as "classMethod"
errors in tests covering unrelated parts of the code.
It's probably worth digging back through commit history and trying to revert
(or otherwise handle) cases where this kind of reordering may have been
unintentionally introduced.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
