On Tue, 10 Sep 2024 16:37:11 GMT, sbgoog <[email protected]> wrote:
> FIleSystemPreferences.lockFile() catches an InterruptedException and just
> returns false, forgetting to re-interrupt the current thread. This leaves the
> caller with no way to observe that the thread was interrupted. This change
> restores the interrupted status on the current thread before returning.
src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 961:
> 959: } catch(InterruptedException e) {
> 960: checkLockFile0ErrorCode(errorCode);
> 961: // Don't lose the interrupt unless we throw.
Why should we lose the interrupted status if we throw a SecurityException? It
doesn't look right.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20938#discussion_r1779019030
