Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop

Darryl Mocek darryl.mocek at oracle.com
Thu Aug 2 21:06:52 UTC 2012


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