<html><body><div dir="ltr"><div style="">
</div><div style=""><div>
<div dir="ltr">Hello,</div><div dir="ltr"><br></div><div dir="ltr">I don’t really understand this discussion,is the normal IO and NIO api not already interpreting error codes? (I am quite sure I often see nationalized error messages in exceptions).</div><div dir="ltr"><br></div><div dir="ltr"><a rel="noreferrer noopener" href="https://github.com/openjdk/jdk/blob/76b9011c9ecb8c0c713a58d034f281ba70d65d4e/src/java.base/unix/classes/sun/nio/fs/UnixException.java#L64">https://github.com/openjdk/jdk/blob/76b9011c9ecb8c0c713a58d034f281ba70d65d4e/src/java.base/unix/classes/sun/nio/fs/UnixException.java#L64</a><br></div><div dir="ltr"><br></div><div dir="ltr"><span style="text-decoration: none; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255); display: inline !important;">I think switching to non-native implementation will not only benefit the error messages.</span><br></div><div dir="ltr"><br></div><div dir="ltr">Gruss</div><div dir="ltr">Bernd</div><div id="ms-outlook-mobile-signature"><div style="direction:ltr">-- </div><div style="direction:ltr">http://bernd.eckenfels.net</div></div>
</div>
<div> </div><hr style="display:inline-block;width:98%" tabindex="-1"><div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif"><b>Von:</b> core-libs-dev <core-libs-dev-retn@openjdk.org> im Auftrag von Matthias Baesken <mbaesken@openjdk.org><br><b>Gesendet:</b> Donnerstag, August 24, 2023 1:47 PM<br><b>An:</b> core-libs-dev@openjdk.org <core-libs-dev@openjdk.org><br><b>Betreff:</b> Re: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock.<div> </div></font></div>On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken <mbaesken@openjdk.org> wrote:
<br>
<br>> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
<br>>
<br>> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock.
<br>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313)
<br>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692)
<br>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008)
<br>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
<br>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvidermain(JShellToolProvider.java:120)
<br>> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock.
<br>> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769)
<br>> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864)
<br>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311)
<br>> [JShell] ... 4 more
<br>>
<br>> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding
<br>
<br>Btw printing just the errno - integer code looks not so nice first but on a lot of distros there are already OS tools that convert it for you so it is easy to get the string from the int value.
<br>
<br>
<br>:~$ apt install moreutils
<br>
<br>:~$ errno 11
<br>EAGAIN 11 Resource temporarily unavailable
<br>
<br>Having said that , I could still hardwire a couple of important errnos on Java level like Roger suggested
<br>> If there are only a couple of errno's that occur for these cases, it might be easier to hardwire the translation.
<br>
<br>-------------
<br>
<br>PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1691522291
<br>
<br></div></div></body></html>