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

[Phil Race]

So in all likelihood the executing thread is going to bail, but Robot 
isn't just used in tests, applications can use it if they want.
I don't know what in practice is likely to cause this exception (other 
than someone deliberately interrupting the thread) and so I find it hard 
to predict what unwanted consequences will manifest.

A test harness timing out a test may be the most likely but in that case 
the test already will be called failed,
does this make that failure "better" ? Perhaps but is this change going 
to help make tests more reliable?

There has to be a positive benefit that makes it worth the compatibility 
risks.

The CSR for this bug needs to call out all of the potential downsides.

-phil.




On 7/9/19 11:01 AM, Sergey Bylokhov wrote:
> On 07/07/2019 16:51, Philip Race wrote:
> 2) However I am still worried by this change of behaviour. We have a 
> sequence of Robot.delay() calls in a typical test and if one of them 
> gets interrupted, then the next one will also return immediately .. 
> since the status is already but right before it returns it will again 
> reset the interrupt status and so the same happens to the next one :
>
> Right, this is what I proposed if the thread was interrupted then all 
> subsequent calls to delay will be skipped(before this fix only the 
> first delay was skipped). So the test will ends immediately, or by 
> some exception if it uses the methods like Thread.sleep(), 
> EventQueue.invokeAndWait() etc.
>
> - Consider this :- public class I { public static void main(String[] 
> args) { Thread.currentThread().interrupt(); try { Thread.sleep(5000); 
> } catch (InterruptedException e) { e.printStackTrace(); } } }
>>
>> java I
>> java.lang.InterruptedException: sleep interrupted
>>      at java.lang.Thread.sleep(Native Method)
>>      at I.main(I.java:5)
>>
>> Are we to update all Robot tests to clear the interrupt status before 
>> calling delay ?
>>
>> Or should delay clear the status on entry to delay ?
>>
>> Or something else ?
> My proposal is do not change any tests or code which use delay(), I 
> guess it is not necessary.
>