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

David Holmes david.holmes at oracle.com
Thu Aug 2 03:05:47 UTC 2012

Hi Stuart,

On 2/08/2012 12:19 PM, Stuart Marks wrote:

On 7/30/12 4:43 PM, David Holmes wrote:

On 31/07/2012 8:27 AM, Darryl Mocek wrote:

Hello core-libs. Please review this webrev to fix Bug #7187876. Webrev can be found here: http://cr.openjdk.java.net/~dmocek/7187876/webrev.00.

The rmi/transport/acceptLoop/CloseServerSocketOnTermination.java test throws ClassCastException due to the Throwable not being of type Error in TCPTransport. Just wondering what type it was? Something that extends Throwable directly? This: throw new Error(t.getMessage(), t.getCause()); loses the type of exception that was thrown. It is better to use: throw new Error(t); The suggestion to use new Error(t) is a good one. 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?

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.

David

s'marks

More information about the core-libs-dev mailing list