Bugzilla – Full Text Bug Listing
| Summary: | NPE in DefaultFoldingStructureProvider.handleProjectionEnabled | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Henrik Lindberg <henrik.lindberg> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | johan.wannheden |
| Version: | 2.0.1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | https://github.com/cloudsmith/geppetto/issues/238 | ||
| Whiteboard: | v2.8.4 | ||
|
Description
Henrik Lindberg
Further investigation revealed that this was caused by using "open file" and opening a file that was not in the workspace. Rather than crashing, I would like to intervene and pop a dialog "opening files external to the workspace is not supported, please use linked files" (or some such). Where is a good place to do that? The exception is from:
protected void handleProjectionEnabled() {
handleProjectionDisabled();
if (isInstalled()) {
initialize();
editor.getDocument().addModelListener(this); // <--- NULL DOCUMENT
}
}
where editor.getDocument() returns null, because XtextDocumentUtil.get(Object) receives a context for an XtextSourceViewer that returns null on getDocument().
Also See https://bugs.eclipse.org/bugs/show_bug.cgi?id=289212 (support opening external files).
I do however just a way to *not open editor with NPE*.
I experimented, and protecting the DefaultFoldingStructureProvider.handleProjectionEnabled from the NPE, just moves the problem elsewhere. The next place is HighlightingReconciler.refresh:243 where editor.getDocument() is called without a check for null.
If that is also fixed, the problem moves to StyledCellLabelProvider, where an assert is made like so:
Assert.isTrue(this.viewer == null && this.column == null, "Label provider instance already in use");
Result is that editor opens up with an ugly "An error has occurred - see log for more details" with the message from the assert being logged.
Trying to protect against the null document seems to be the wrong approach.
I'm facing a similar problem when trying to open a file outside the workspace (using an implementation of LanguageSpecificURIEditorOpener). The exceptions raised are those descriped in http://stackoverflow.com/questions/8239458/cannot-open-workspace-external-file-in-xtext-based-plugin. fixed in 2.8.4 *** This bug has been marked as a duplicate of bug 470557 *** |