Does AsynchronousSocketChannel.read(ByteBuffer) throw ShutdownChannelGroupException?

[Gili]

AsynchronousSocketChannel.read(ByteBuffer) overrides AsynchronousByteChannel.read(ByteBuffer). The latter has no concept of ChannelGroups so it does not declare that the method may throw ShutdownChannelGroupException. AsynchronousSocketChannel, on the other hand, declares that all I/O operation will throw ShutdownChannelGroupException if the channel group is shut down in the middle of an operation.

There seems to be a conflict of specifications. Doesn't Design by Contract specify that a subclass may throw less exceptions but it may not throw new exceptions? I know that technically speaking all methods throw RuntimeException but that's a little dirty. This exception does not indicate programming error and it is quite reasonable to expect that developers will want to catch it. At the very least, AsynchronousSocketChannel.read(ByteBuffer)'s documentation should address this more explicitly.

Thank you,
Gili

[Alan Bateman]

Gili wrote:

> AsynchronousSocketChannel.read(ByteBuffer) overrides
> AsynchronousByteChannel.read(ByteBuffer). The latter has no concept of
> ChannelGroups so it does not declare that the method may throw
> ShutdownChannelGroupException. AsynchronousSocketChannel, on the other hand,
> declares that all I/O operation will throw ShutdownChannelGroupException if
> the channel group is shut down in the middle of an operation.
>
> There seems to be a conflict of specifications. Doesn't Design by Contract
> specify that a subclass may throw less exceptions but it may not throw new
> exceptions? I know that technically speaking all methods throw
> RuntimeException but that's a little dirty. This exception does not indicate
> programming error and it is quite reasonable to expect that developers will
> want to catch it. At the very least,
> AsynchronousSocketChannel.read(ByteBuffer)'s documentation should address
> this more explicitly.
>  

It's just an oversight that the ShutdownChannelGroupException is missing
from the list of possible exceptions - I'll fix that thanks!

As regards shutdown while there are I/O operations outstanding - it
depends on if you use the shutdown or shutdownNow methods. The shutdown
method does a graceful shutdown and does not impact the outstanding I/O
operations. The shutdowNow method is to do a forceful shutdown and this
is specified to close all open channels in the group. This causes all
outstanding I/O operations to fail with AsynchronousCloseException.

-Alan.

[Gili]

Alan Bateman wrote:

> Gili wrote:
>> AsynchronousSocketChannel.read(ByteBuffer) overrides
>> AsynchronousByteChannel.read(ByteBuffer). The latter has no concept of
>> ChannelGroups so it does not declare that the method may throw
>> ShutdownChannelGroupException. AsynchronousSocketChannel, on the other
>> hand,
>> declares that all I/O operation will throw
>> ShutdownChannelGroupException if
>> the channel group is shut down in the middle of an operation.
>>
>> There seems to be a conflict of specifications. Doesn't Design by
>> Contract
>> specify that a subclass may throw less exceptions but it may not throw
>> new
>> exceptions? I know that technically speaking all methods throw
>> RuntimeException but that's a little dirty. This exception does not
>> indicate
>> programming error and it is quite reasonable to expect that developers
>> will
>> want to catch it. At the very least,
>> AsynchronousSocketChannel.read(ByteBuffer)'s documentation should address
>> this more explicitly.
>>  
> It's just an oversight that the ShutdownChannelGroupException is missing
> from the list of possible exceptions - I'll fix that thanks!
>
> As regards shutdown while there are I/O operations outstanding - it
> depends on if you use the shutdown or shutdownNow methods. The shutdown
> method does a graceful shutdown and does not impact the outstanding I/O
> operations. The shutdowNow method is to do a forceful shutdown and this
> is specified to close all open channels in the group. This causes all
> outstanding I/O operations to fail with AsynchronousCloseException.

        I'm confused. If shutdownNow() causes outstanding operations to throw
AsynchronousCloseException when does ShutdownChannelGroupException get
thrown?

Thanks,
Gili

[Alan Bateman]

cowwoc wrote:
> :
>     I'm confused. If shutdownNow() causes outstanding operations to
> throw AsynchronousCloseException when does
> ShutdownChannelGroupException get thrown?
If you look at the open methods you will see that they are specified to
throw ShutdownChannelGroupException if you attempt to open a channel in
a group that is shutdown.

Also, the I/O methods where you specify a completion handler, and
attempt to initiate an I/O operation on a channel in a group that has
terminated. This case has to fail with the initiating thread throwing an
exception (because the completion handler cannot be invoked).

-Alan.

[Gili]

Alan Bateman wrote:

> cowwoc wrote:
>> :
>>     I'm confused. If shutdownNow() causes outstanding operations to
>> throw AsynchronousCloseException when does
>> ShutdownChannelGroupException get thrown?
> If you look at the open methods you will see that they are specified to
> throw ShutdownChannelGroupException if you attempt to open a channel in
> a group that is shutdown.
>
> Also, the I/O methods where you specify a completion handler, and
> attempt to initiate an I/O operation on a channel in a group that has
> terminated. This case has to fail with the initiating thread throwing an
> exception (because the completion handler cannot be invoked).
>
> -Alan.

        Last I checked, Future does not guarantee that its implementation is
thread safe. Does it?

Gili