+1
Also I think it is more consistent with things we already do at the moment. For
example there is already a ConnectException, ChannelClosedException etc which
is also just an IOException with a “special” errno value.
Just my 2 cents,
Norman
> On 7 Dec 2016, at 15:01, David M. Lloyd <david.ll...@redhat.com> wrote:
>
> 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>
>> <mailto: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
