Bug 392708 - NPE when editor contains non-conforming text
Summary: NPE when editor contains non-conforming text
Status: CLOSED FIXED
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.3.0   Edit
Hardware: PC Mac OS X
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: bugday
Depends on:
Blocks:
 
Reported: 2012-10-23 23:35 EDT by Alex Ruiz CLA
Modified: 2012-12-03 05:04 EST (History)
4 users (show)

See Also:
sebastian.zarnekow: kepler+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Ruiz CLA 2012-10-23 23:35:14 EDT 
On one of our Xtext-based editors, we found an NPE every time we open a file that contains a particular sequence of text that does not conform with the grammar. The same happens when typing the same text in an empty file.

Here is a sample of the stack trace:

java.lang.NullPointerException
	at org.eclipse.xtext.EcoreUtil2.getContainerOfType(EcoreUtil2.java:100)
	at org.eclipse.xtext.GrammarUtil.containingAssignment(GrammarUtil.java:95)

I fixed this temporarily by overriding the default ILocationInFileProvider in the runtime Guice module. I pretty much extended DefaultLocationInFileProvider and overrode findNodeFor(EObject) adding checks for null. 

It would be great if containingAssignment or getContainerOfType check for null EObjects.

Thanks,
-Alex
Comment 1 Holger Schill CLA 2012-12-03 04:12:45 EST 
Has been already fixed some days ago git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=5b5eeedcd55f9fdb78c9eef19f3e0c77a35af52e
Comment 2 Knut Wannheden CLA 2012-12-03 05:04:34 EST 
That getContainerOfType() refactoring actually contained an accidental change of contract. But I don't see any problem with returning 'null' on 'null' input. Does anyone disagree?