Bugzilla – Full Text Bug Listing
| Summary: | Resource Exception in ModelManager when deleting closed project | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Marko Tomljenovic <marko.tomljenovic> |
| Component: | cdt-core | Assignee: | Project Inbox <cdt-core-inbox> |
| Status: | REOPENED --- | QA Contact: | Jonah Graham <jonah> |
| Severity: | normal | ||
| Priority: | P3 | CC: | john.cortell, malaperle |
| Version: | 7.0.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 366393 | ||
| Bug Blocks: | |||
|
Description
Marko Tomljenovic
I tried to reproduce this and I'm a little bit confused. The only way I had this exception is if I removed the try catch block in this part
CModelManager.resourceChanged
...
case IResourceChangeEvent.PRE_DELETE :
try {
if (resource.getType() == IResource.PROJECT &&
( ((IProject)resource).hasNature(CProjectNature.C_NATURE_ID) ||
((IProject)resource).hasNature(CCProjectNature.CC_NATURE_ID) )){
this.preDeleteProject((IProject) resource);}
} catch (CoreException e) {
}
break;
Also, the line CModelManager.java:890 didn't match to a Project.hasNature call in 7.0.2. Could it be possible that you have a modified version of CDT 7.0.2?
(In reply to comment #1) > I tried to reproduce this and I'm a little bit confused. The only way I had > this exception is if I removed the try catch block in this part > > CModelManager.resourceChanged > ... > > case IResourceChangeEvent.PRE_DELETE : > try { > if (resource.getType() == IResource.PROJECT && > ( ((IProject)resource).hasNature(CProjectNature.C_NATURE_ID) || > ((IProject)resource).hasNature(CCProjectNature.CC_NATURE_ID) )){ > this.preDeleteProject((IProject) resource);} > } catch (CoreException e) { > } > break; > > Also, the line CModelManager.java:890 didn't match to a Project.hasNature call > in 7.0.2. Could it be possible that you have a modified version of CDT 7.0.2? I compared "my" version with yours. The only difference is that in my version the catched CoreException is logged where in your version it is simply not regarded at all. This issue can be closed from my point of view. The only question is whether not regarding a CoreException here is the right and specified way. Closing as per last comment. I've seen the trick of ignoring exceptions from closed projects in other places in CDT a well. We just recently tweaked Freescale's copy of platform to throw a specialization of CoreException that we check and ignore. CDT shouldn't be reporting exceptions to the Error log when such exceptions are expected and acceptable. The problem is that the way the exception is thrown in the platform doesn't allow CDT to reliably know if it's one of these harmless exceptions or not. I'll ask Serge Beauchamp to pursue contributing the platform change and I'll contribute the CDT part of it. If you read comment#1 and comment#2 stock CDT doesn't report such an exception. A forked (or older) version of CDT does that. But I don't mind if this gets fixed the right way of course. Is there any bug on platform side? (In reply to comment #5) > If you read comment#1 and comment#2 stock CDT doesn't report such an exception. > A forked (or older) version of CDT does that. But I don't mind if this gets > fixed the right way of course. Is there any bug on platform side? Well, eating any CoreExceptions that can happen in that code is definitely not ideal. We only want to eat the core exception that happens as a result of the project being closed. Again, properly making that distinction isn't possible today but if Serge is on board for contributing the change to the platform, then we can improve the situation in CDT. I or Serge will open a platform bug soon. |