Hi
If you use CoreException and IStatus there is a MultiStatus.
Regards
Ed Willink
Jurgen Vinju wrote:
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
_______________________________________________
imp-dev mailing list
imp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/imp-dev
|
