Bugzilla – Full Text Bug Listing
| Summary: | [quick assist] Exception while processing quick fixes or quick assists | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Marcel Bruch <marcel.bruch> |
| Component: | Core | Assignee: | Jay Arthanareeswaran <jarthana> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jarthana, markus.kell.r, noopur_gupta |
| Version: | 4.5 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
Marcel Bruch
Little more context:
public class myJob extends Job {
@Override
protected IStatus run(IProgressMonitor monitor) {
monitor.beginTask("Analyzing", IProgressMonitor.UNKNOWN);
if (isModal(this)) {
new
} else {
setProperty(IProgressConstants.KEEP_PROPERTY, Boolean.TRUE);
setProperty(IProgressConstants.ACTION_PROPERTY, new Acti|<>on() { // <--- press CMD+1 on Action()
@Override
public void run() {
MessageDialog.openInformation(null, "...", "");
}
});
}
return Status.OK_STATUS;
}
At QuickAssistProcessor.java:508, the code is: ((IType) anonymTypeBinding.getJavaElement()) With the given example, "anonymTypeBinding" comes as: Anonymous type : (id=NoId) final class $Local$ ... However, anonymTypeBinding.getJavaElement() returns a ResolvedSourceMethod: IStatus run(IProgressMonitor) which results in CCE. Moving to JDT/Core for comments on why a ResolvedSourceMethod is returned instead of a ResolvedSourceType for the anonymous type binding. (In reply to Noopur Gupta from comment #2) > Moving to JDT/Core for comments on why a ResolvedSourceMethod is returned > instead of a ResolvedSourceType for the anonymous type binding. Looks like a bug, I will investigate why it is so. I can reproduce in master as well as 4.3 and 4.2. The broken code is causing the anonymous types to be not-available and hence getElementAt() returns the enclosing method as the element. We can probably do an instanceof check and avoid the CCE. I don't see what else we can do here. I'd say the bug is that the Java model doesn't contain the anonymous type, although the AST recovery could come up with a ClassInstanceCreation node. If there's no way to get the right IType element, then doing a sanity check and returning null would probably be better in this case. But this needs to be documented in the API (as specific as possible -- not just "can return null"). (In reply to Markus Keller from comment #5) > I'd say the bug is that the Java model doesn't contain the anonymous type, > although the AST recovery could come up with a ClassInstanceCreation node. Yep, to add some more details, in case there is a compilation error in the code surrounding the anonymous type, in this case, the if/else statement, the ASTNode.HasLocalType flag is not. But the construction of Java element for the anonymous types depends on this bit being set. The code and doc changes are here: https://git.eclipse.org/r/32371 With this, there is at least one NPE on the jdt.ui that should be taken care of. Until then, this can wait. (In reply to Jayaprakash Arthanareeswaran from comment #7) The problem with that proposal is that it's still a breaking API change for most clients. The API of IBinding#getJavaElement() guarantees to return non-null except in a few cases that can easily be ruled out by clients. Either by construction (client e.g. knows that the type of an exception always has a Java element), or by explicit tests (e.g. checking the 'synthetic' flag). The org.eclipse.jdt.ui project alone has 105 references to this method, and if we don't have a simple rule to protect us from NPEs, then we have to make a pass over all these references and add workarounds / error handling for cases where it now can return null. That would be OK for internal code, but not for public APIs. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |