Community
Participate
Working Groups
If an Editor part throws a PartInitException during initialization (in the org.eclipse.ui.IEditorPart#init(IEditorSite, IEditorInput) method), the Action Bars are not cleaned up properly. This can cause problems. In my case I had following behavior: 1) An editor of type 1 would throw the PartInitException (and it has some toolbar actions defined) 2) Eclipse would deal with that and not display the editor (or the toolbar) 3) Another editor type (type 2) with a toolbar is invoked and everything opens properly 4) Close editor of type 2 - the toolbar of the editor type 1 is displayed and cannot be removed until the application is restarted. I have tracked this down to the org.eclipse.ui.internal.EditorManager#createSite(...). Before calling part.init (), it creates action bars but if init() throws an exception they are not disposed of. I checked the closeEditor method in the same class - it invokes the disposeEditorActionBars() method which is supposed to clean up the action bars. There are really no valid work-arounds (except not throwing the PartInititException which is part of the API) - all of these classes and methods are internal and even access private fields that are not exposed through getters. It seems that createSite() should catch the exception, call the disposeEditorActionBars() method and then re-throw.
This only happens on an error condition, which shouldn't only happen during the development process.
From Dusko Misic: ---------------- The reason why we marked the bug as 'Major' initially is that it is important for us that it gets fixed in 3.1. We are afraid that is not going to happen if its severity is 'Normal'. The fix seems very simple. On the other hand, to change our system not to throw the PartInitException (which is part of the public API anyway and is only way to indicate to Eclipse that the editor will not open) would be major undertaking. Basically, a lot of constructs assume that if that editor is open that it has right context and in this use case it wouldn't have. Could you let us know if the bug is going to be fixed for 3.1?
Okay, let me look a bit closer. My initial reaction was to treat this as low priority, and to not go out of my way to fix it for 3.1. What is the behaviour in 3.0 (or 3.0.1)?
It is 3.0.1 but I believe that the behavior is the same in 3.0. Basically, the editor part interface (org.eclipse.ui.IEditorPart) has method with following signature: public void init(IEditorSite site, IEditorInput input) throws PartInitException; The PartInitException is thrown to indicate that the part (editor) cannot be initialized. Here is the quote from the javadoc: ‘Implementors of this method must examine the editor input object type to determine if it is understood. If not, the implementor must throw a PartInitException.’ If that happens, Eclipse aborts creation of the editor and rolls back any contributions, objects, state changes, etc. done in order to create/open this editor. Of course, it is the editor’s responsibility to clean up things that it itself initialized before throwing the exception. The end result is that the Eclipse does not open the editor, displays the localized error msg (from the exception) and clean things up. The only exception to this rule is the bug in the org.eclipse.ui.internal.EditorManager#createSite(…) that does not perform the clean up. In our case, that results in orphaned toolbars. Please note that there are very real use cases when the editor’s input type is not understood. Our use case was the user creating manually a dummy file with one of the extensions for which our editors are registered. The editor requires proper file structure so it cannot initialize correctly. A work around would be to still display the editor but with completely different content – basically a different implementation of the editor. That leads to another set of problems – all of those above mentioned things (like initialized toolbar) are not really valid anymore and can (and will) cause more problems. It should be very easy to fix this problem. The EditorManager already has the method that performs the cleanup (disposeEditorActionBars). It just needs to be called in createSite(…) if the PartInitException happens and then re-throw the exception.
Just to clarify, this problem exists in 3.0.1?
I believe this problem exists in 3.0 and 3.0.1, but does not exist in 2.1.3. I believe this is a regression over 2.1.3 that must be fixed (violates API). I'm proposing this fix be considered for a 3.0.2 release.
Yeech. Even if we get the action bars cleaned up properly, I've got a number of other PRs relating to bad things happening when an editor or view throws an exception on initialization. We should really fix all of them, and that's a big patch. Because of all the formatting in 3.1, it's a real pain trying to get big patches working in both streams. I'd suggest flagging this for 3.1 (and not 3.0.2).
If you are having problems, then do the following: 1.) Format all source code you want to change on the maintenance branch and commit. 2.) If necessary, format all source code you want to change on the development branch and commit. 3.) Make your patch. I still feel this particular problem is important for 3.0.2. I don't know about any of the other problems....
I believe this is the change introduced between revision 1.37 and 1.38 of EditorManager. This is supposed to be the fix for Bug 59301.
Fixed in the maintenence stream. Reviewed with DP.
Created attachment 15402 [details] Patch for org.eclipse.ui.workbench The patch that was applied. We wrapper the init method call and dispose the action bars/site in the event that the init method failed for any reason.
Marking as fixed.
Also fixed in HEAD. The fix in HEAD differs in that there is now a new message in properties file to describe the error condition better.
Verified in 200411022000 for 3.1M3
Ooops, didnt mean to mark that as verified. Leaving open for 3.0.2
Again marking as fixed.
Verified in 200502161722
Verified in 3.0.2 200502161722 (Linux/Motif)
This bug may need to be re-verified on the 3.1 stream, as the fix has changed due to bug 87468
