Bug 12219 - Self Encapsulate Field throws NullPointerException
Summary: Self Encapsulate Field throws NullPointerException
Status: RESOLVED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.0 M5   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-03-25 10:38 EST by Steve Cannon CLA
Modified: 2002-03-28 18:49 EST (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Cannon CLA 2002-03-25 10:38:10 EST 
Triggering a "Self Encapsulate Field" using the UI causes a 
Message "Cannot proceed due to the following problem"

Problem is "Internal Error while creating a change object.  
See log for details."

Error occurs for private, public, and protected fields in a
large number of classes.  Using build 20020214. 

problem apparently in DefaultBindingResolver.resolveNameForNameReference

Log shows the following.  


Log: Mon Mar 25 10:24:18 EST 2002
4 org.eclipse.jdt.ui 1 Internal Error
java.lang.reflect.InvocationTargetException: java.lang.NullPointerException
	at 
org.eclipse.jdt.core.dom.DefaultBindingResolver.resolveNameForNameReference
(DefaultBindingResolver.java:222)
	at org.eclipse.jdt.core.dom.DefaultBindingResolver.resolveName
(DefaultBindingResolver.java:97)
	at org.eclipse.jdt.core.dom.Name.resolveBinding(Name.java:75)
	at org.eclipse.jdt.internal.corext.refactoring.sef.AccessAnalyzer.visit
(AccessAnalyzer.java:74)
	at org.eclipse.jdt.core.dom.SimpleName.accept0(SimpleName.java:85)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:1025)
	at org.eclipse.jdt.core.dom.QualifiedName.accept0(QualifiedName.java:86)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:1025)
	at org.eclipse.jdt.core.dom.InfixExpression.accept0
(InfixExpression.java:264)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:1025)
	at org.eclipse.jdt.core.dom.VariableDeclarationFragment.accept0
(VariableDeclarationFragment.java:96)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:1049)
	at org.eclipse.jdt.core.dom.FieldDeclaration.accept0
(FieldDeclaration.java:119)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:1049)
	at org.eclipse.jdt.core.dom.TypeDeclaration.accept0
(TypeDeclaration.java:163)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:1049)
	at org.eclipse.jdt.core.dom.CompilationUnit.accept0
(CompilationUnit.java:143)
	at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:981)
	at 
org.eclipse.jdt.internal.corext.refactoring.sef.SelfEncapsulateFieldRefactoring.
checkInput(SelfEncapsulateFieldRefactoring.java:206)
	at org.eclipse.jdt.internal.ui.refactoring.CheckConditionsOperation.run
(CheckConditionsOperation.java:58)
	at org.eclipse.jdt.internal.ui.refactoring.CreateChangeOperation.run
(CreateChangeOperation.java:93)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run
(ModalContext.java:98)
Comment 1 Olivier Thomann CLA 2002-03-25 11:19:37 EST 
This has been completely rewritten since the 0214 build. Could you please test your code with the 
latest stable build? If it still occurs, let me annotate this PR and add a reproducable test case. 
Without it, it is almost impossible to reproduce a problem and therefore to fix it.
Thanks for 
your report.
Comment 2 Olivier Thomann CLA 2002-03-25 12:16:48 EST 
Closed since the reporter confirmed that this problem is gone with the latest stable build.