If you're already having to turn the native error code into (say) an
enum or something, it's effectively equivalent to just having different
types for every error code. The difference is just like:
try {
...
} catch (IOException e) {
switch (e.getErrorCode()) {
case ECONNRESET: return;
case ENFILE: System.out.println("No file descriptors
remain"); return;
default: throw e; // no idea
}
}
versus:
try {
...
} catch (ConnectionResetException ignored) {
} catch (NoFilesRemainingException e) {
System.out.println("No file descriptors remain");
}
I like the latter better in probably 95%+ of situations.
On 12/06/2016 05:14 AM, Langer, Christoph 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
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
--
- DML
