Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop

[David Holmes]

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