AsynchronousSocketChannel: abortable operations throw RuntimeException
Alan Bateman
Alan.Bateman at oracle.com
Thu Oct 14 02:25:30 PDT 2010
Gili wrote:
> :
> Excellent. Regarding AsynchronousSocketChannel, I wasn't implying that the
> stream should be reusable after an abort. I was implying that the decision
> whether to support or use aborting should occur at compile-time instead of
> at runtime. Meaning:
>
> 1) Each implementation must specify whether it supports aborting in its
> Javadoc
> 2) The interface should provide a method to query this capability at runtime
> (in case someone has no way of knowing what implementation gets passed into
> their method at runtime). This method should guarantee a constant value
> throughout runtime (i.e. it's a compile-time decision).
> 3) The implementation should continue to throw IllegalStateException, but
> users shouldn't need to trigger a read/write to find out whether the
> implementation supports aborting because of #1 and #2. The
> IllegalStateException is simply an indication that they should know better.
>
> Do you agree?
>
> Gili
>
I think by compile-time you actually mean at runtime because whether an
implementation can cancel the underlying I/O operation or not, is highly
implementation specific, and not something that is known at compile
time. It's not clear to me that a
supportsCancelWithGuaranteeThatNoBytesWereTransferred or some such
method is really all that useful here. As I said, an
AsynchronousSocketChannel is connected to a stream and you will almost
always close the channel when there is an error, like a timeout.
-Alan.
More information about the nio-discuss
mailing list