[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [imp-dev] Re: Bug in IMP runtime re: service creation
|
I guys,
I have a strong opinion. Especially Stan's last remark coincides with my intentions for that part of the code. I want the client to decide what to do with the exceptions, log them or act upon them in different ways.
* The extension loading stuff is too much of a utility to enforce a certain kind of exception handling.
* Logged exceptions may to be ignored at development time, it makes the code "artificially" robust, leading to unused or old code that does not work but also does no immediate harm.
So, let's make an aggregate exception. Is there a facility for that in the Java standard library or Eclipse Core? Otherwise, we should make our own.
Cheers,
Jurgen
On Wed, Oct 7, 2009 at 10:53 PM, Stan Sutton
<suttons@xxxxxxxxxx> wrote:
Hi Bob,
So I guess this might occur, for instance,
when there are five refactoring contributors, and exceptions occur in the
attempt to instantiate three of them.
I'm in favor of logging all of the exceptions/errors
individually. Seems like it would be uninformative to return just
the last as an exception, and confusing to return them all in one aggregate
exception.
It also seems like a good idea to allow
the instantiated services to be returned and for the client to continue
normally (or as normally as it can). So that argues for not
throwing an exception, right? (I mean, is it possible both to throw
an exception and have the successfully instantiated services returned?)
At the same time, a client might want
to know whether there were any problems in loading services. If no
exception is thrown, then that would have to be done by some other means.
A client could examine the error log, but that seems too cumbersome.
Is it possible to have the ExtensionFactory maintain some status
information that a client could query to check for problems with service
instantiation?
Regards,
Stan
Stan Sutton, Ph. D.
IBM T. J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532 USA
telephone: 1-914-784-7316, FAX: 1-914-784-7455, T/L 863
e-mail: suttons@xxxxxxxxxx, Stan Sutton/Watson/IBM@IBMUS
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)
_______________________________________________
imp-dev mailing list
imp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/imp-dev
--
Jurgen Vinju
Centrum Wiskunde & Informatica - SEN1
phone: +31205924102
www :
http://www.cwi.nl,
http://www.meta-environment.nl,
http://homepages.cwi.nl/~jurgenv,
http://twitter.com/jurgenvinju
skype: jurgen.vinju