Community
Participate
Working Groups
try to create a type 'test' in junit.framework Log: Mon Dec 17 16:32:34 GMT+01:00 2001 4 org.eclipse.jdt.ui 1 Internal Error org.eclipse.jdt.core.JavaModelException[966]: org.eclipse.core.internal.resources.ResourceException: A resource exists with a different case: /y/f/junit/framework/Test.java. at org.eclipse.core.internal.resources.Resource.checkDoesNotExist (Resource.java:973) at org.eclipse.core.internal.resources.File.create(File.java:81) at org.eclipse.jdt.internal.core.JavaModelOperation.createFile (JavaModelOperation.java:180) at org.eclipse.jdt.internal.core.CreateCompilationUnitOperation.executeOperation (CreateCompilationUnitOperation.java:64) at org.eclipse.jdt.internal.core.JavaModelOperation.execute (JavaModelOperation.java:268) at org.eclipse.jdt.internal.core.JavaModelOperation.run (JavaModelOperation.java:476) at org.eclipse.core.internal.resources.Workspace.run (Workspace.java:1232) at org.eclipse.jdt.internal.core.JavaModelManager.runOperation (JavaModelManager.java:1139) at org.eclipse.jdt.internal.core.JavaElement.runOperation (JavaElement.java:518) at org.eclipse.jdt.internal.core.CompilationUnit.createType (CompilationUnit.java:133) at org.eclipse.jdt.internal.ui.wizards.TypePage.createType (TypePage.java:1165) at org.eclipse.jdt.internal.ui.wizards.TypePage$1.run (TypePage.java:1387) at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute (WorkspaceModifyDelegatingOperation.java:39) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run (WorkspaceModifyOperation.java:64) at org.eclipse.core.internal.resources.Workspace.run (Workspace.java:1232) at org.eclipse.ui.actions.WorkspaceModifyOperation.run (WorkspaceModifyOperation.java:78) at org.eclipse.jface.operation.ModalContext.runInCurrentThread (ModalContext.java:296) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:249) at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:713) at org.eclipse.jdt.internal.ui.wizards.NewElementWizard.finishPage (NewElementWizard.java:74) at org.eclipse.jdt.internal.ui.wizards.NewClassCreationWizard.performFinish (NewClassCreationWizard.java:42) at org.eclipse.jface.wizard.WizardDialog.finishPressed (WizardDialog.java:570) at org.eclipse.jface.wizard.WizardDialog.buttonPressed (WizardDialog.java:311) at org.eclipse.jface.dialogs.Dialog$1.widgetSelected(Dialog.java:211) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java (Compiled Code)) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java(Compiled Code)) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java(Compiled Code)) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java (Compiled Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java (Compiled Code)) at org.eclipse.jface.window.Window.runEventLoop(Window.java(Compiled Code)) at org.eclipse.jface.window.Window.open(Window.java:523) at org.eclipse.jdt.internal.ui.wizards.AbstractOpenWizardAction.run (AbstractOpenWizardAction.java:143) at org.eclipse.jdt.internal.ui.wizards.AbstractOpenWizardAction.run (AbstractOpenWizardAction.java:161) at org.eclipse.ui.internal.PluginAction.run(PluginAction.java:181) at org.eclipse.jface.action.Action.runWithEvent(Action.java:452) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:407) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent (ActionContributionItem.java:361) at org.eclipse.jface.action.ActionContributionItem.access$0 (ActionContributionItem.java:352) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent (ActionContributionItem.java:47) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java(Compiled Code)) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java(Compiled Code)) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java (Compiled Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java (Compiled Code)) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java (Compiled Code)) at org.eclipse.ui.internal.Workbench.run(Workbench.java:758) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:820) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:285) at SlimLauncher.main(SlimLauncher.java:14)
the wizard should have a guard for this case
A error dialog informs about the problem. This is the only thing I can do. There is no chance to know about the problem before file creation time. Could CORE offer a method like canCreate() that has the OS specifics? The check would not give any guarantee of the success of the operation, but lets wizards warn about OS specific problems: names, existing files, already existing folder with the same name ect. The current check routines are general file name checks and not context sensitive. Moving to Core
I would argue against providing such API. We already provide name and path validation methods on IWorkspace for things that can be checked quickly. Many of the error cases that can occur during creation are difficult or impossible to detect. To do so would also duplicate much functionality implemented by the java class libraries and the underlying filesystem, making it more difficult to support and maintain our code base across our various target platforms. It would also clutter our API to provide ifICallThisMethodDoYouThinkItWillSucceed() companion methods for all the operations provided by core (move, copy, delete, create, etc). I suggest that the current behaviour is close to acceptable. I think the UI should just remove references to "Core exception" and "Internal Error", and just present the message provided by core to the user. It shouldn't add log entries for this either, it's normal behaviour. The core message that is returned, "A resource exists with a different case...", tells the user exactly what's wrong and they'll know how to proceed.
I agree that this is a tricky and painful area to implement, but having it will give more quality to, for example, the wizard. I see many other clients of the functionality, refactoring to name one. They try hard to warn users about problems before applying any change, as rollback is difficult. It becomes very hard when an exception occurs.
i wholeheartedly agree - putting code like try{ createClass() } catch (CoreException e){ if (isThisSimplyTheDifferentCase6998BugException(e)) notReallyAnError(e) else realError(e) } is EVIL! i have a hard time imagining this kind code to ever be legit in the ui. also, what if i want to create a composite command action that (as one of its leaves) creates, or renames, a file. the suggested semantics makes it next to impossible to implements this cleanly. the necessary exception handling dance would not be pretty.
There are many other kinds of exceptions that can occur during create(), and they can't all be detected beforehand. Therefore callers of create() have to be able to handle exceptions thrown by create() regardless. Case collisions are just one kind of error out of many. Core provides a different error code if clients wish to handle case collisions differently, but no one is forcing them to do so. Why isn't it sufficient to just report the exception to the user in this case? What would the notReallyAnError() method do differently in your pseudo-code example? See also Core RFC 0001 on the Platform Core web page.
Of course, create can always throw a CoreException, but the more predetection, the better the quality of wizards / the tool, and less troubles for refactoring.
No changes planned for 2.0
Reopening for investigation.
Not planning to change this behaviour. Closing.
It's not that we ask for changing the behaviour. We were asking for additional checking method to be able to avoid the exception. Such checking methods ('canDelete') are platform dependend code which should be abstracted by core. As a GUI we are interested to be able to warn about problems, we can't let code crash in the middle of a refactoring modifying 100 files.
Old title: [resources] CoreException in new class wizard
*** Bug 52114 has been marked as a duplicate of this bug. ***
Closing bugs we don't plan to fix.
Note that this bug still hurts us. We're currently implementing workarounds in several wizards, implementing a 'canCreate' check by doing extra java.io.File.exists() before invoking IFile.create. bug 60246 is an example.
*** Bug 66979 has been marked as a duplicate of this bug. ***
