| [imp-dev] Bug in IMP runtime re: service creation |
| Hi All, Seems we have an exception handling bug in the language service instantiation portion of the IMP runtime. [The following applies only to language service extension points that permit multiple service implementations per language, e.g., refactoringContributor.] Specifically, ExtensionFactory.getLanguageServiceSet() has the following code, which iterates over the extensions of a given language service extension point: for (int n = 0; n < elements.length; n++) { IConfigurationElement element = elements[n]; ILanguageService service = loadLanguageService(extensionPoint, language, "class", element); if (service != null) { result.add(service); } } Now, loadLanguageService() can throw an ExtensionException, so the above for loop can terminate early. Moreover, notice where the exception handling is performed in the following call chain: ServiceFactory.getRefactoringContributors() -> ServiceFactory.loadServices() -> ServiceFactory.createExtensions() <== catches ExtensionException, but returns an empty service set in that case -> ExtensionFactory.createServiceExtensionSet() -> ExtensionFactory.createServiceExtensionSetForPlugin() -> ExtensionFactory.getLanguageServiceSet() -> ExtensionFactory.loadLanguageService() <== throws various flavors of ExtensionException As a result, if for any reason the framework can't instantiate one language service implementation class, no service implementations are returned, even if others were already successfully instantiated. At first blush, the solution is obvious: Make sure that all of the successfully-instantiated service implementations are returned. Now to the real reason for my note: Several exceptions could be caught while attempting to instantiate the service implementation classes for a given extension point, so a single ExtensionException can presently only hold the information for one failed attempt. The main purpose of the exception (AFAICT) is to provide good information for the Error Log. Our options, as I see them: - Keep the control flow as is, but return only the ExtensionException for the last failure. - Keep the control flow as is, but return a single exception that aggregates all the ExtensionExceptions encountered. - Log the exception right away and indicate failure for that particular service implementation by returning null, which will simply not be added to the set of service implementations returned to the client (usually the UniversalEditor). - ??? Comments? -- Cheers, - Bob ------------------------------------------------- Robert M. Fuhrer Research Staff Member Programming Technologies Dept. IBM T.J. Watson Research Center IMP Project Lead (http://www.eclipse.org/imp) X10: Productivity for High-Performance Parallel Programming (http://x10-lang.org) |