AsynchrnousSocketChannel: abortable operations throw RuntimeException

Alan Bateman Alan.Bateman at oracle.com
Wed Oct 13 04:39:01 PDT 2010


Gili wrote:
> Hi Alan,
>
> I don't recall if we discussed this before, but I'd like to improve upon "a
> subsequent attempt to initiate a read operation causes an unspecified
> runtime exception to be thrown" found in the AsynchrnousSocketChannel
> JavaDoc. I have three problems with this approach:
>
> 1) Can users do anything reasonable with this information? Am I really
> supposed to provide two implementations of my code depending on whether or
> not aborting happens to be supported at runtime?
>
> 2) You must read/write to find out if your implementation supports aborting
> I/O operations. Shouldn't this information be accessible at compile-time?
> Consider java.nio.ByteBuffer. Depending on how the object was constructed it
> might or might not support optional operations. Note that you know at
> compile-time exactly what operations the implementation will support (and if
> you make a mistake you end up with a specific RuntimeException subclass).
>
> 3) Why not specify the exception that will be thrown? Look at it from the
> developer's point of view: the only way for me to find out if the
> implementation does not support aborting I/O operations is to catch all
> documented exceptions. If a RuntimeException is *still* thrown then we
> assume aborting is not supported. I find this problematic because most
> classes I've seen will throw undocumented RuntimeExceptions that have
> nothing to do with indicating an abortable I/O operation (instead they
> correspond to some programming error or unrecoverable failure).
>
> I'd like to hear your thoughts on the matter.
>
> Thanks,
> Gili
>   
AsynchronousSocketChannel is connected to a stream connection so it 
doesn't really make sense to continue to use the connection after an I/O 
operation has been cancelled. However, you are right and this should 
really be an IllegalStateException (which is what our implementation 
does, but it's just not specified). I'll create a bug to track this.

-Alan


More information about the nio-discuss mailing list