While the idea is good I think this will not “fly” because for windows winsock 
is used in the JDK. Winsock does not use the same error constant as bsd sockets 
API (with errno).
In windows we would need to expose “WSAGetLastError()” values and in 
unix/linux/bsd “errno” values. Sure we could try to map for "WSAGetLastError()" 
values to unix/linux/bsd “errno” values but I am not sure this is possible in 
all cases.

That said we do exactly what you suggest edin netty with our own native 
transport that currently only supports linux [1].

[1] 
https://github.com/netty/netty/blob/4.1/transport-native-epoll/src/main/java/io/netty/channel/unix/Errors.java#L73
 
<https://github.com/netty/netty/blob/4.1/transport-native-epoll/src/main/java/io/netty/channel/unix/Errors.java#L73>
 .



> On 5 Dec 2016, at 20:09, Bernd Eckenfels <e...@zusammenkunft.net> wrote:
> 
> Hello,
> 
> I know it is a radical idea, but what about exposing errno value in an 
> IOException.
> 
>  I do think that the new ConnectionRefused subtype is helpful, but for each 
> seldomly occuring error case a dedicated exception is more work than a one 
> time mapping of native errormcodes to fields.
> 
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net <http://bernd.eckenfels.net/>
> 
> 
> 
> On Mon, Dec 5, 2016 at 7:28 PM +0100, "Norman Maurer" 
> <norman.mau...@googlemail.com <mailto:norman.mau...@googlemail.com>> wrote:
> 
> 
> > Am 05.12.2016 um 18:48 schrieb David M. Lloyd :
> > 
> >> On 12/05/2016 06:29 AM, Norman Maurer wrote:
> >> Hi all,
> >> 
> >> I wonder if it would be possible to add a new public exception time for 
> >> the situation of an SocketChannel.accept(…) or SocketChannel.open(…)  (and 
> >> the same for ServerSocket / Socket) failing because of too many open files.
> >> The reason is because especially when acting as a server such an exception 
> >> may be something you can easily recover from. At there is basically no way 
> >> to detect if this was the cause of an IOException or not.
> >> 
> >> On unix / linux this are the errno values:
> >> 
> >> [EMFILE]           The per-process descriptor table is full.
> >> [ENFILE]           The system file table is full.
> >> 
> >> For netty we would love to be able to know if this was the case of the 
> >> problem and if so just stop accepting for a period of time to help the 
> >> system to recover.
> >> 
> >> What others think about this ?
> > 
> > I like the idea, but maybe it should be a general IOException since this 
> > same error can happen on file open, selector creation (sometimes), pipe 
> > creation, etc.
> > 
> > -- 
> > - DML
> 
> Sure that would work for me as well :)
> 
> Bye,
> Norman

Reply via email to