If we go this route we should also reconsider: https://bugs.openjdk.java.net/browse/JDK-8167161 <https://bugs.openjdk.java.net/browse/JDK-8167161>
Still not sure what solution I would prefer tho. > On 6 Dec 2016, at 12:14, Langer, Christoph <christoph.lan...@sap.com> wrote: > > 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 <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
