[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [gmf-dev] [GMF - API CHANGE] Bugzilla 115700: DemuxingMListener notifies clients that resource is loaded even when the load actually failed
|
Hi, Chris!
I have a question concerning new way to work
with resources: Should I surround ResourceUtil.loadResource() with try-catch
block or can I just ask resource for an errors? If you suppose that an exception
could be thrown from the .loadResource() code, why don't declare this exception
explicitly in a method signature?
______________
Alex Shatalin
Description:
In the past, clients have come to expect that if they call
ResourceUtil.load() or MEditingDomain.loadResource() the resource would be
automatically unloaded if there were errors during the load. Also, client
MListeners did not expect to receive any events during this atomic
operation.
There are drawbacks to this
approach:
1) If the client calls aResource.load()
directly, then there is no automatic unloading of the resource. It is the same
if a client causes a proxy to resolve.
2) The
exception that is provided on the ResourceUtil.load() or
MEditingDomain.loadResource() is only one of many possible exceptions that
were produced during the load. EMF chooses one of the exceptions to be
actually thrown back to the MSL. Sometimes this exception by itself is not
sufficient to discover the root of the problem. The other exceptions are
available in the resource object's getErrors() method. When a resource is
unloaded then these errors are cleared out. If the resource is automatically
unloaded then the client could have difficulty tracking down the true problem
with the model file.
As part of the defect fix,
the old behaviour has been re-instated for all MListeners in GMF
M4.
Clients need to do the following to migrate
their code before they adopt GMF M5:
1) All MListeners
that will fail if they are given a resource with no contents should check the
resource's errors list first before continuing:
public void handleResourceLoadedEvent(Notification notification,
Resource resource) {
if
(!resource.getErrors().isEmpty()) {
return;
}
// proceed with listener actions
}
public void onEvent(List events) {
// Extract a resource loaded
notification from the list of events and the notifier resource for the
event
if (!resource.getErrors().isEmpty())
{
return;
}
// proceed as normal
}
2) Callers to
ResourceUtil.load(String path, ...) or MEditingDomain.loadResource(String
path,...) should change their code to something like the following:
Resource res = anEditingDomain.findResource(path,
...);
if (res == null) {
res = anEditingDomain.createResource(path,
...);
}
if
(!res.isLoaded()) {
try
{
anEditingDomain.loadResource(res);
} catch (Exception e) {
res.getErrors(); // Examine
the errors, maybe log them somehow or even show them to the user?
res.unload(); // We don't need the errors anymore, unload the resource to
clean up.
}
}
3) Callers to
ResourceUtil.unload(...) or MEdtingDomain.unload(...) should call
aResource.unload() instead.
New
API Availability:
This afternoon in the GMF repository as part of
M4.
Old API Removal:
Beginning of M5 unless clients request
more time.
Tracking:
Bugzilla
115700
Clients Taken Care of:
The runtime EMF core plugin of GMF only.
Other Clients' Action:
Perform the migration mentioned above as soon as
the client adopts the M4 driver and before they adopt M5.
_________________________________
Chris McGee,
BCS
Software Developer
Rational Software, IBM Software Group
770
Palladium Drive, Ottawa, ON, Canada
tel: (613)
591-2918