Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop

[Darryl Mocek]

OK, not attachments allowed.  Webrev can be found here: 
http://cr.openjdk.java.net/~dmocek/7187876/webrev.02

Darryl

On Thu 02 Aug 2012 02:06:52 PM PDT, Darryl Mocek wrote:
>
> 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