Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop (original) (raw)

Darryl Mocek darryl.mocek at oracle.com
Thu Aug 2 21:14:28 UTC 2012

OK, not attachments allowed. Webrev can be found here: http://cr.openjdk.java.net/~dmocek/7187876/webrev.02

Darryl

On Thu 02 Aug 2012 02:06:52 PM PDT, Darryl Mocek wrote:

Let's try again... Darryl On Thu 02 Aug 2012 01:50:05 PM PDT, Darryl Mocek wrote:

Patch attached using UndeclaredThrowableException. Darryl On Wed 01 Aug 2012 09:13:55 PM PDT, Stuart Marks wrote:

On 8/1/12 8:05 PM, David Holmes wrote:

This case is kind of pathological. The CloseServerSocketOnTermination test injects an exception of an arbitrary type into the accept loop of an RMI connection. (See the test to see how it does this; it's rather clever.) The cast error occurs when the exception that's injected is an instance of Throwable. I see. Can the real code actually throw an arbitrary subclass of Throwable? It potentially can. At least, this code isn't under the control of RMI. The exception/throwable might be thrown from calls on a ServerSocket (or subclass) created by an RMIServerSocketFactory, which is supplied by the user. It's hard to conceive why it would throw something other than Error or Exception, but you never know what those darned users are going to do. :-)

Oh, one more thing. Mike Duigou pointed out to me that there is something called UndeclaredThrowableException. Should we throw new UndeclaredThrowableException(t) instead? It is semantically more correct as that is what we have - Throwable suclasses are checked exceptions unless Errors or RuntimeExceptions. OK, let's go with UndeclaredThrowableException then. Thanks. s'marks

More information about the core-libs-dev mailing list