Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop

David Holmes david.holmes at
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:
>>> The rmi/transport/acceptLoop/ 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.


> s'marks

More information about the core-libs-dev mailing list