Community
Participate
Working Groups
1. Create a simple Java project with two trivial classes, Class1 and Class2. 2. Open a Java editor on each class, ensuring that **Class2's** editor totally obscures **Class1's** (i.e., don't tile the editors). 3. Shut down Eclipse and restart it. Things should look pretty much the same as before. 4. Choose "New Window" from the Window menu. 5. In the new window, delete Class1 using the Package Explorer. 6. Go to the original window. You'll notice the editor for Class1 is still there. Click on its tab. Kablooie. Obscured editors aren't instantiated on startup---only when they're revealed. The error comes from FileEditorInputFactory when it tries to reload the editor's memento information: the memento's path points to the now-deleted resource.
*** Bug 38830 has been marked as a duplicate of this bug. ***
You seem to have already done some digging on this problem. Where exactly in FileEditorInputFactory is the problem - createElement? What error message did you see? Was there anything in the .log file? Which build, exactly, were you using?
> Where exactly in FileEditorInputFactory is the problem - > createElement? Right: public IAdaptable createElement(IMemento memento) { // Get the file name. String fileName = memento.getString(TAG_PATH); if (fileName == null) return null; // Create an IResource. IResource res = ResourcesPlugin.getWorkspace().getRoot().findMember(new Path (fileName)); if (res instanceof IFile) return new FileEditorInput((IFile)res); else return null; } "res" ends up being null because the file has been deleted at this point. > What error message did you see? An "Unable to Restore Editor" dialog containing: Unable to restore: Class1.java Reason": Unable to create editor: Class1.java. > Was there anything in the .log file? Yes, but the stack trace isn't useful because the error is reported asynchronously. > Which build, exactly, were you using? 200303272130
We should improve the message displayed to the user. We will not be able to restore the editor, so we can at least tell the user the real reason why - its because the file no longer exist. Its not quite the same behavior as when the editor is restored before the file is deleted. In that case, the editor already has its content and be shown. Only on save do we warn the user the file is was deleted and has the option of saving under a new name (or the existing name to recreate the file).
I'm not sure why you want to notify the user at all. You close visible editors silently; why not close obscured editors silently too?
What do you mean that we close visible editors silently? Can you provide a scenario where that happens?
An example lives in my original description of the problem: The editor of Class1 will close automatically when you delete Class.java. In fact, any editor of Class1, in any top-level view of the Eclipse workbench, will close silently-- -that is, iff it has been restored. If not, then you get the dreaded error dialog.
Changed the FileEditorInputFactory to return a handle to an IFile instead of actually checking for the existance of an IFile. The editor then can handle the case of a file handle to a resource that does not exist in the workspace anymore. With this fix, the Java editor will come to the top, and display in its text area that the file <file name> does not exist. The user can then close the editor. As for your previous comment, you'll need to open a bug report against Platform - Text. The workbench makes no attempt to close editors when resources are deleted. The text editor (which the Java editor is based on) must do this on its own.
*** Bug 38863 has been marked as a duplicate of this bug. ***
