Community
Participate
Working Groups
Created attachment 209689 [details] stack trace When Dali calls ITypeBinding.getInterfaces() it throws an AbortCompilation exception, seemingly when the project's build path points to a missing JRE. See attached stack trace.
What is the behavior do you expect to see here ?
No exception? The API doc does not indicate an AbortCompilation exception might be thrown. Other methods in ITypeBinding seem to handle AbortCompilation. See the code for TypeBinding.isAssignmentCompatible(ITypeBinding): It returns false if it catches an AbortCompilation. (See bug 143013.) I'm not sure what *should* happen. What is the intent of the entire ITypeBinding interface in this situation? The method getInterfaces() could return an array with the problematic interface(s) removed, or it could return an empty array if *any* interface is problematic. In any case, the JavaDoc should describe the behavior. Given the other code in TypeBinding that handles the exception, it seems like something similar should happen here. What do you think?
I've looked at this a bit closer. I had some problems figuring out exactly what was happening because both the JDT code and the Dali code have exception handlers that would catch any exceptions; and, just to complicate things, the Dali code was executing on a long-running background thread.... Anyway: Despite my initial description, TypeBinding.getInterfaces() *is* catching and logging the exception and returning an empty array. It is catching RuntimeException instead of AbortCompilation (as I was looking for...). My mistake was reacting to the stack trace appearing in the Error Log. I thought Dali was logging the exception; but it was TypeBinding.getInterfaces() that was logging the error. Seems like that is the expected behavior. Sorry about the confusion.
Verified for 3.8 M5
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.
AbortCompilation should never be surfaced to clients.
This bug's state is a bit confusing by now. We had verified for 3.8 M5 that the exception is not surfaced but caught and logged. The re-open in comment 5 does not question this fact but is an RFE to only change the way this exception is logged when caught. To resolve this confusion I've moved the new RFE to its own bug 406317. The original problem in this bug has been resolved and verified OK.
Restoring the original fix status.
(In reply to comment #7) Agreed.
