Bug 131921 - NPE caugth in DefaultBindingResolver.resolveName(Name)
Summary: NPE caugth in DefaultBindingResolver.resolveName(Name)
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2 M6   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-15 08:47 EST by Martin Aeschlimann CLA
Modified: 2006-03-28 08:41 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 Martin Aeschlimann CLA 2006-03-15 08:47:35 EST 
20060315

When debugging, I normally catch NPE by default.

DefaultBindingResolver.resolveName(Name) line: 1061 any many other places catch RuntimeExceptions 

try {
  if (internalScope == null) {
    binding = this.scope.getTypeOrPackage(....);
  } else {
    ...
  }
} catch (RuntimeException e) {
  // see https://bugs.eclipse.org/bugs/show_bug.cgi?id=53357
}
In my example I got plenty of NPE cought as 'this.scope' was null.
However, comment of bug 53357 only mentions AbortCompilation

IMO this is very risky practice as this hides many potential problems, e.g. ArrayOutOfBoundExceptions, IllegalArgumentExeptions, Assertions

In the given scenario, it also would be more performant to add a simple if (scope != null) at the beginning.

My setup:
- connect to :pserver:anonymous@dev.eclipse.org:/cvsroot/webtools
- checkout org.eclipse.wst.validation
- open EMFWorkbenchContextFactory
Comment 1 Olivier Thomann CLA 2006-03-20 14:35:05 EST 
this.scope should not be null.
I can change it to catch only AbortCompilation, but I would prefer to get a reproducable test case first. I tried the steps that you specified and I could not get a NPE.
Comment 2 Olivier Thomann CLA 2006-03-20 15:20:55 EST 
In fact, this.scope can be null in case of errors. I still would like to get a reproducable test case.
I released a version that is checking for null and only catch AbortCompilation.
Let me know if this is fixing your issue since I cannot reproduce it.
Comment 3 Martin Aeschlimann CLA 2006-03-20 17:01:51 EST 
My scenarion was as described, and I don't know what else caused the problems.
Unfortunatly , I currently don't have time to reproduce it. But I think it is good that you added the null checks.
Comment 4 Olivier Thomann CLA 2006-03-21 11:19:48 EST 
Closing as FIXED.
If you get a chance to verify it before M6 is released, it would be really nice.
Comment 5 Jerome Lanneluc CLA 2006-03-28 08:41:19 EST 
Verified for 3.2 M6 using build I20060328-0010