Community
Participate
Working Groups
Version: 3.3.0 Build id: I20060804-0010 Scenario : - unset the auto buid option if it is set; - create PDE projects PA and PB, with Java project; - add the following to the manifest file: Eclipse-JREBundle: true - make PA depend on PB and PB depend on PA; set the compiler preference for cycles to warning; - create package java.lang in both projects; - create the following sources: PA/src/java/lang/Object.java package java.lang; public class Object { Class getClass() { return null; } public String toString() { return ""; } } PB/src/java/lang/Class.java package java.lang; public class Class { String getName() { return "noname"; } } - use the 'Update Classpath' PDT tool for both projects; build should succeed; - remove the JRE from both build paths, rebuild; should fail; - in any of the source files, add a white space and save; should get an exception which starts with: !STACK 0 org.eclipse.jdt.internal.compiler.problem.AbortCompilationUnit at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.abor t(CompilationUnitDeclaration.java:92) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(Probl emHandler.java:121) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(Prob lemReporter.java:1772) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPath Correct(ProblemReporter.java:3434) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getResolve dType(LookupEnvironment.java:862) at org.eclipse.jdt.internal.compiler.lookup.Scope.getJavaLangString(Scop e.java:1949) at org.eclipse.jdt.core.dom.DefaultBindingResolver.resolveExpressionType (DefaultBindingResolver.java:523) at org.eclipse.jdt.core.dom.Expression.resolveTypeBinding(Expression.jav a:108) at org.eclipse.jdt.internal.corext.refactoring.code.flow.ReturnFlowInfo. getReturnFlag(ReturnFlowInfo.java:31) at org.eclipse.jdt.internal.corext.refactoring.code.flow.ReturnFlowInfo. <init>(ReturnFlowInfo.java:19) at org.eclipse.jdt.internal.corext.refactoring.code.flow.FlowAnalyzer.cr eateReturn(FlowAnalyzer.java:165) at org.eclipse.jdt.internal.corext.refactoring.code.flow.FlowAnalyzer.en dVisit(FlowAnalyzer.java:748) at org.eclipse.jdt.core.dom.ReturnStatement.accept0(ReturnStatement.java :137) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2466) at org.eclipse.jdt.internal.corext.refactoring.code.flow.InOutFlowAnalyz er.perform(InOutFlowAnalyzer.java:40) at org.eclipse.jdt.internal.ui.search.MethodExitsFinder.markReferences(M ethodExitsFinder.java:123) at org.eclipse.jdt.internal.ui.search.MethodExitsFinder.perform(MethodEx itsFinder.java:95) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.updateOccurrenceAnn otations(JavaEditor.java:3060) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$ActivationListener. windowActivated(JavaEditor.java:1427) at org.eclipse.ui.internal.Workbench$8.run(Workbench.java:606) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.Workbench.fireWindowActivated(Workbench.java: 604) at org.eclipse.ui.internal.WorkbenchWindow$7.shellActivated(WorkbenchWin dow.java:2683) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java: 164)
The AbortCompilationUnit is thrown on a call to Expression.resolveTypeBinding. This exeception isn't speced there and should not be surfaced but handled in jdt.core.
There are 2 issues here. 1. UI being resilient to internal failures 2. Core trapping some of its known exceptions, like this one. We could catch it and resend some spec'ed exception, or simply answer some null value... But (1) is still an issue, if let say, there is a NPE in the compiler...
I don't think we should change anything here regarding catching RuntimeExceptions. It's normally done in the display loop, or as here in the SafeRunnable that was installed for window activaation listeners.
The current patch for bug 114349 clearly influences the behavior observed here. For one thing, it is improved because we no more have any error poping up (hence it fixes the original bug). Interestingly enough, something is not perfect yet since the first build after the removal of the JREs shows no error on Class and Object in the navigation view (it shows them in the editor though). Editing one of those files and rebuilding results into the expected mark in the navigation view, for the edited file only. Editing the other file completes the expected marks set in the navigation view.
Released for 3.3M4. Added regression test org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0659
Verified for 3.3 M4 using build I20061212-0010 (running test case using 3.3 M3 raises the AbortCompilationUnit exception)
