Bug 488563 - AssertionError when becomeWorkingCopy is called with no underlying XtextResource
Summary: AssertionError when becomeWorkingCopy is called with no underlying XtextResource
Status: RESOLVED FIXED
Alias: None
Product: Handly
Classification: Technology
Component: Xtext Integration (show other bugs)
Version: 0.4   Edit
Hardware: All All
: P3 normal
Target Milestone: 0.5   Edit
Assignee: Vladimir Piskarev CLA
QA Contact:
URL:
Whiteboard: breakingchange
Keywords: api
Depends on:
Blocks:
 
Reported: 2016-02-26 09:07 EST by Vladimir Piskarev CLA
Modified: 2016-02-26 09:57 EST (History)
0 users

See Also:

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 Vladimir Piskarev CLA 2016-02-26 09:07:16 EST 
Steps to reproduce:

1. Open a .foo file with the Foo editor the basic example provides

2. Delete the file

3. Navigate back to the deleted file (Navigate -> Back)

4. A broken Foo editor opens with the message 'Editor could not be initialized', the details being 'AssertionError: Working copy creation was not completed.'

Expected behavior:

A Foo editor opens without error and indicates that the file does not exist.

Stack trace:

java.lang.AssertionError: Working copy creation was not completed. Ill-behaved working copy buffer?
	at org.eclipse.handly.model.impl.WorkingCopyInfo$InitTask.run(WorkingCopyInfo.java:185)
	at org.eclipse.handly.model.impl.WorkingCopyInfo$InitTask.access$0(WorkingCopyInfo.java:180)
	at org.eclipse.handly.model.impl.WorkingCopyInfo$InitTask$1.call(WorkingCopyInfo.java:133)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at org.eclipse.handly.model.impl.WorkingCopyInfo$InitTask.execute(WorkingCopyInfo.java:143)
	at org.eclipse.handly.model.impl.SourceFile.becomeWorkingCopy(SourceFile.java:223)
	at org.eclipse.handly.model.impl.SourceFile.becomeWorkingCopy(SourceFile.java:156)
	at org.eclipse.handly.xtext.ui.editor.HandlyXtextEditorCallback.createWorkingCopy(HandlyXtextEditorCallback.java:202)
	at org.eclipse.handly.xtext.ui.editor.HandlyXtextEditorCallback.afterSetInput(HandlyXtextEditorCallback.java:120)
	at org.eclipse.xtext.ui.editor.CompoundXtextEditorCallback.afterSetInput(CompoundXtextEditorCallback.java:108)
	at org.eclipse.xtext.ui.editor.XtextEditor.doSetInput(XtextEditor.java:249)
...
Comment 1 Vladimir Piskarev CLA 2016-02-26 09:27:46 EST 
Initial analysis:

HandlyXtextDocument.T2MReconcilingUnitOfWork currently does nothing if resource is null. In particular, it doesn't notify XtextWorkingCopyBuffer (an IReconcilingListener), so SourceFile.ReconcileOperation is not called and WorkingCopyInfo is not marked as created, hence the AssertionError.

It seems reasonable for T2MReconcilingUnitOfWork to throw a dedicated exception when resource == null && force == true rather than to return normally. The exception can then be caught and handled gracefully. This will require a contract change in IHandlyXtextDocument#reconcile (a new exception type would be added). Strictly speaking, this is a breaking change.