Community
Participate
Working Groups
From Bug 368986 comment 5: In Xtext the binding API is used to create EMF-based facades of the java types, since it's very common to have unresolved type references in a workspace the error log is full of AbortCompilation errors. I'm reopening because I'd like to suggest logging the AbortCompilation with a DEBUG severity or provide a way to configure it.
*** Bug 409739 has been marked as a duplicate of this bug. ***
What would be the point of reference for configuring the severity of Abort exceptions? Individual API like ITypeBinding.getInterfaces() (see Bug 368986 comment 0) are certainly not the place where we want to add a parameter. I wonder if a preceding use of ASTParser (w/ setResolveBindings(true)) should setup the environment for suppressing this logging? Would that work in the relevant use cases? Or where do you originally obtain the ITypeBinding from?
If I remember correctly, I haven't seen this for a while. The binding is obtained like this: IType jdtType = project.find... ASTParser parser = ASTParser.newParser(AST.JLS3); parser.setWorkingCopyOwner(workingCopyOwner); parser.setIgnoreMethodBodies(true); parser.setProject(jdtType.getJavaProject()); IBinding[] bindings = parser.createBindings(new IJavaElement[] { jdtType }, null);
Btw: I don't thing this has to be configurable, but an operation that is expected to handle an error condition gracefully, should not necessarily log stuff to the console.
What I also see is a stacktrace like this, which indiates that other places also log AbortCompilation errors: org.eclipse.jdt.internal.compiler.problem.AbortCompilation: Pb(324) The type org.eclipse.core.runtime.Plugin cannot be resolved. It is indirectly referenced from required .class files at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:135) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:201) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:2176) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect(ProblemReporter.java:4211) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:59) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:133) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superclass(BinaryTypeBinding.java:1349) at org.eclipse.jdt.core.dom.TypeBinding.getSuperclass(TypeBinding.java:807)
(In reply to Sebastian Zarnekow from comment #5) > What I also see is a stacktrace like this, which indiates that other places > also log AbortCompilation errors: thanks, this means that any fix will have to connect several (unconnected?) locations in the code. My current thinking is that - new API on ASTParser could set a flag to ignore any Abort exceptions - this would be stored in DefaultBindingResolver (shared by all bindings) - relevant operations in dom.TypeBinding and family consult that flag (I currently see 10 candidate locations calling Util.log())
