<AWT Dev> [12] Review Request: 8210231 Robot.delay() catches InterruptedException and prints stacktrace to stderr.

[Sergey Bylokhov]

On 30/10/2018 15:52, Philip Race wrote:
> But Robot.delay() is inherently a long lived operation, so interrupts are
> more likely there. And you *are* changing behaviour. So I am still
> unconvinced this is right. When might this matter in practice in writing tests ?

This might matter for example if the next sequence of code is interrupted by the test harness:
Robot.delay(10);
EventQueue.invokeAndWait(...); or any other code which may throw "InterruptedException".

Depending on when the interrupt will happen the test will continue or will stop, the fix will removed this dependency.

> 
> -phil.
> 
> On 10/30/18, 3:17 PM, Sergey Bylokhov wrote:
>> On 30/10/2018 14:03, Phil Race wrote:
>>> But the docs for Robot.delay() state :
>>>
>>> >  To catch any |InterruptedException|s that occur, |Thread.sleep()| may be used instead.
>>>
>>> So to my reading it is telling you "this call will completely swallow thread interrupts".
>>
>> This is what I have tried to follow, if the user need to catch the InterruptedException then Thread.sleep() should be used. Otherwise the Robot.delay() may be used, which will be transparent to the Thread.interrupt(). I mean behavior will not be depend on the moment when interrupt was called, before Robot.delay(), inside Robot.delay() or right after the Robot.delay().
>>
>>>
>>> And you are changing that and I don't think you should.
>>> It has nothing to do with removing the printStackTrace which is the only
>>> change requested by the submitter.
>>>
>>> -phil.
>>>
>>> On 10/30/18 11:04 AM, Sergey Bylokhov wrote:
>>>> Hi, Phil.
>>>>
>>>> On 30/10/2018 10:34, Phil Race wrote:
>>>>> Can you explain why you are doing this ?
>>>>> Thread.sleep() clears the IE so why do you need to restore it ?
>>>>> It just looks like an un-specified and un-needed change of behaviour to me.
>>>>
>>>> It is done to "notify" other code which follows Robot.delay() that the thread was interrupted.
>>>>
>>>> So for example before the fix the code below depended on when the thread.interrupt() was called:
>>>>   Robot.delay(10);
>>>>   EventQueue.invokeAndWait(...);
>>>>
>>>> If the method "interrupt()" was called by the application, when invokeAndWait () was called, then the thread will be stopped as expected.
>>>> But if the method "interrupt()" is called during Robot.delay(10), the application will miss the fact that the flow was interrupted.
>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>> On 10/7/18 9:56 PM, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review the fix for jdk12.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210231
>>>>>> Webrev: http://cr.openjdk.java.net/~serb/8210231/webrev.00
>>>>>>
>>>>>> The Robot.delay() is a simple wrapper on top of Thread.sleep(), which ignores the InterruptedException. But in case of InterruptedException it prints the stack trace, which is unspecified behavior.
>>>>>>
>>>>>> In the fix the "printStackTrace()" was removed, and the interrupted state of the thread is restored.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>


-- 
Best regards, Sergey.