AsynchrnousSocketChannel: abortable operations throw RuntimeException

[Gili]

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
-- 
View this message in context: http://nio-discuss.970641.n3.nabble.com/AsynchrnousSocketChannel-abortable-operations-throw-RuntimeException-tp1692482p1692482.html
Sent from the nio-discuss mailing list archive at Nabble.com.