Bugzilla – Full Text Bug Listing
| Summary: | [EFS] Null pointer exception when getting path of FileEditorInput whose file does not exist | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Gregory Dow <dow> | ||||
| Component: | IDE | Assignee: | Tod Creasey <Tod_Creasey> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | john.arthorne, n.a.edgar | ||||
| Version: | 3.3 | Flags: | Tod_Creasey:
review?
(john.arthorne) |
||||
| Target Milestone: | 3.4 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | hasPatch | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 188448, 199770 | ||||||
| Attachments: |
|
||||||
Adding John to help with this - I am not sure that there is anything we can do in the 3.3 timeframe - we should fail more gracefully with this I suggest reverting to the 3.2 behaviour in this case, and return null from the getPath method. if (locationURI == null) return null; Many callers do check for null when calling getPath, so they will be better off. The same situation occurs for FileEditorInput.getURI(), which also returns null in this case. Ideally IPathEditorInput and IURIEditorInput should specify the behaviour in this case - perhaps something to revisit after 3.3. This was my gut feeling as well but my concern was that null was never expressed as a valid value for IPathEditorInput#getPath. Would clarifying the javadoc be considered an API change? Bug 188448 has been logged for the javadoc update which we will have to wait until 3.4 for. I agree with John's assessment - honouring he 3.2 behaviour of returning null in that case is the way to go. Created attachment 68207 [details]
Patch
Patch to emulate the 3.0 behaviour. Note we need 2 null checks in the end.
Fix released for build >20070628 *** Bug 194819 has been marked as a duplicate of this bug. *** Verified in I20070807-0010 Note that this solution has been integrated into the solution for Bug 199770. |
The problem occurs in my plugin when I call FileEditorInput.getPath for a file that has been deleted on disk. This happens when you have an editor open, and then delete its project and choose the option to delete the files on disk. The built-in Eclipse editors do not run into the problem because they present a dialog asking to save or close the file and do not allow any interaction with the file. The stack trace is: java.lang.NullPointerException at org.eclipse.core.internal.filesystem.InternalFileSystemCore.getStore(InternalFileSystemCore.java:104) at org.eclipse.core.filesystem.EFS.getStore(EFS.java:350) at org.eclipse.ui.part.FileEditorInput.getPath(FileEditorInput.java:175) In FileEditorInput.getPath, the code is: final URI locationURI = file.getLocationURI(); IFileStore store = EFS.getStore(locationURI); IResources.getLocationURI is documented to return null if no URI can be determined. I believe that the code above should check for (locationURI == null) and return null. This null pointer exception occurs with Eclipse 3.3M7, but not with 3.2. A workaround for this problem is to not call IEditorInput.getPath() if IEditorInput.exists() returns false.