Community
Participate
Working Groups
I20170119-2000. 1. Change JavaSourceViewerConfiguration to use the asynchronous content assistant 2. Start a target workbench 3. Paste "class Test {m}" into the Package Explorer 4. Invoke content assist after m ==> Invalid thread access ==> no proposals, and no error dialog that informs the user See "normal" content assistant on how it should look like.
(In reply to Dani Megert from comment #0) > ==> no proposals, and no error dialog that informs the user At this point, I don't think an error dialog is the best way to render such error to user; moreover, such error should rather be perceived as a bug in the proposal computer than in the content assistant itself. That said, it's still worth reporting it. What would you think about showing in the proposal list an error entry "Error computing some proposals, see log for details" ? The benefit would be that it shows the feedback in its context rather than showing a pop-up, and doesn't "interrupt" the expected flow.
(In reply to Mickael Istria from comment #1) > (In reply to Dani Megert from comment #0) > > ==> no proposals, and no error dialog that informs the user > > At this point, I don't think an error dialog is the best way to render such > error to user; moreover, such error should rather be perceived as a bug in > the proposal computer than in the content assistant itself. That said, it's > still worth reporting it. I think you did not read my comment 0 and look how it is done in the normal content assistant. Please do so before we continue to discuss.
Sorry, I had the JDT completion processor error reporting in mind. I fully agree errors should be handled the same way for async (using ExceptionLoggingSafeRunnable and fLastErrorMessage). I'll try to have it patched for tomorrow build, but to be honest, I'm not that confident I'll manage to have it in time... Whether to show it to user in the completion pop-up or not is another story.
New Gerrit change created: https://git.eclipse.org/r/89872
*** Bug 558977 has been marked as a duplicate of this bug. ***
@Mickael: I also noticed that content assist processor seems to be blacklisted once the throw an exception is this intentional?
(In reply to Christoph Laeubrich from comment #6) > @Mickael: I also noticed that content assist processor seems to be > blacklisted once the throw an exception is this intentional? In JDT, it is intentional. In general, I don't think it's intentional.
I'm currently adding content-assist for an editor that calls an external tool, if that tool fails the following happens: - no content assist is shown, no error is show to the user - my content assist processor seems to be never called again I just can't tell if (async) contest assist itself is "dead" at that point or my processor gets black-listed somehow. If I reopen the editor everything is back to normal.
