Christoph, You should not remove conversion codes (platform string to Java String) at JNU_ThrowByNameWithLastError, and you have to add conversion codes at JNU_ThrowByNameWithMessageAndLastError.
It seems that you assume strerror returns only ascii characters, but actually not. It depends on the locale of your environment where java programs runs. -Kenji Kazumura In message <decc19cdab854bbeac7126cb8e236...@dewdfe13de11.global.corp.sap> RFR 8158023: SocketExceptions contain too little information sometimes "Langer, Christoph" <christoph.lan...@sap.com> wrote: > Hi all, > > please review the following change: > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 > > During error analysis I stumbled over a place where I encountered a > SocketException which was thrown along with some strerror information as > message. I found it hard to find the originating code spot with that > information. > > So I looked at the places where we throw exceptions, namely JNU_Throw... and > NET_Throw... functions and came up with the following enhancement: > - NET_ThrowByNameWithLastError can go completely as it does not provide any > benefit over JNU_ThrowByNameWithLastError. > - JNU_ThrowByNameWithLastError can be cleaned up. > > - I added JNU_ThrowByNameWithMessageAndLastError to print out a string like > message + ": " + last error. > > - I went over all places where NET_ThrowByNameWithLastError is used and > replaced it appropriately. > > Do you think this change is desirable/possible? > > Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev > as well as JNU_Throw... code affects all. > > Best regards > Christoph >
