Retry fetching clipboard contents when it initially fails #6443
Conversation
matthiasblaesing
added
DO NOT squash
Platform
| @@ -437,7 +461,8 @@ public void run() { | |||
| catch (ThreadDeath ex) { | |||
| throw ex; | |||
| } | |||
| catch (Throwable ignore) { | |||
| catch (InterruptedException | RuntimeException ex) { | |||
| log.log(Level.FINE, "systemClipboard not available", ex); // NOI18N | |||
There was a problem hiding this comment.
Again, I'd do Level.INFO here, especially since we could here catch exceptions other than the known IllegalStateException from Clipboard.getContents.
| // that is used because accessing the clipboard can block | ||
| // indefinitely. Running the access loop here is deemed similar | ||
| // in nature. | ||
| final int MAX_TRIES = 50; |
There was a problem hiding this comment.
Is there a reason to handle this issue differently in GetContents from SetContents? I think without good reason they should handle this in the same way, whether it be this way or that way being open to question.
The pro and con of rescheduling rather than looping is that anything waiting on the task won't wait for the rescheduled one.
|
Pushed an update, that should address the concerns. I did not change the logic of |
|
Makes sense to keep the distinction then, or at least |
|
So updated this with the timeout requested by @mbien. Shall we get this in? |
|
Thanks for the adjustments! Looks good! |
matthiasblaesing
force-pushed
the
clipboard2
branch
from
ffe687f
to
0e226f2
Compare
It was reported, that clipboard copy/paste actions sometimes fail in
NetBeans (#3962). It was reported, that even with logging enabled no
exception was visible.
Clipboard#setContents and Clipboard#getContents are both documentent
that they can throw IllegalStateException when the clipboard can't be
accessed.
There are two changes here:
GetContents#run, the exception will notbe swallowed, but reported on level
FINE(just as the rest of the logging)clipboard don't interrupt all NetBeans copy operations.