RFR 8158023: SocketExceptions contain too little information sometimes

[Kenji Kazumura]

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 <decc19cdab854bbeac7126cb8e236f1e at DEWDFE13DE11.global.corp.sap>
   RFR 8158023: SocketExceptions contain too little information sometimes
   "Langer, Christoph" <christoph.langer at 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
>