Hi,

I would also support if IOException could be enriched to expose the native 
error code. However, the user then would need to evaluate this code in a 
platform specific manner. Maybe there could be some class/interface which would 
help to translate platform specific error codes to common constants for common 
error types.

Best regards
Christoph

From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Bernd 
Eckenfels
Sent: Montag, 5. Dezember 2016 20:09
To: net-dev@openjdk.java.net
Subject: Re: Special exception for EMFILE / ENFILE when using sockets.

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



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