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.
