Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop
david.holmes at oracle.com
Thu Aug 2 03:05:47 UTC 2012
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
>> 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.
More information about the core-libs-dev