Community
Participate
Working Groups
Build ID: 3.4.1 Steps To Reproduce: 1. have customers environment with blocked internet access 2. try to find updates using "SimplePlanner.updatesFor" 3. See application crash with unexpected and uncaught exception More information: This operation cancelled exception causes the trouble, I'm hoping we can get a ECF call that declares this OperationCancelledException instead of just throwing it... org.eclipse.core.runtime.OperationCanceledException at org.eclipse.equinox.internal.p2.metadata.repository.ECFMetadataTransport.getLastModified(ECFMetadataTransport.java:143) at org.eclipse.equinox.internal.p2.metadata.repository.CacheManager.createCache(CacheManager.java:69) at org.eclipse.equinox.internal.provisional.spi.p2.metadata.repository.SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory.java:59) at org.eclipse.equinox.internal.provisional.spi.p2.metadata.repository.SimpleMetadataRepositoryFactory.validateAndLoad(SimpleMetadataRepositoryFactory.java:97) at org.eclipse.equinox.internal.provisional.spi.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:85) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:485) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:452) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:435) at org.eclipse.equinox.internal.p2.director.SimplePlanner.updatesFor(SimplePlanner.java:384)
Two issues here: a) should document @throws OperationCanceledException as this method has no other way to signal cancelation b) The claim is that there was never any explicit user cancelation, so the exception may have been thrown incorrectly in this case. I suspect since Henrik has since rewritten a lot of this stuff that this might no longer be an issue.
(In reply to comment #1) > Two issues here: > > a) should document @throws OperationCanceledException as this method has no > other way to signal cancelation > > b) The claim is that there was never any explicit user cancelation, so the > exception may have been thrown incorrectly in this case. I suspect since Henrik > has since rewritten a lot of this stuff that this might no longer be an issue. > I reviewed what is on HEAD a) It is documented at the lowest level at least (in RepositoryTransport), and this method now takes a monitor as an argument. b) the new impl only throws an OperationCanceledException if there is a monitor and the monitor has been canceled. Afaict the ECF code involved (at least for http requests) does not throw OperationCanceledException.
(In reply to comment #2) Guys, thanks for looking at this, I know it's a weird one. John explained the implications of OperationCanceledExcetion on p2-dev, I'm now aware of the fact that by throwing this exception the UI should get a chance to know about a canceled operation.. From what I see in M6 the principal system has not changed, ECFMetadataTransport#getLastModified still takes in no progress monitor but throws a OperationCanceledException, so the potential for an application crash is still there. For now I'm fine with catching that exception out there no Planner.updatesFor, I'm just wondering if I can remove the catch clause for 3.5 or not, from what Hendrik said it should be enough to use "null" as progress monitor for planner.updatesFor, or am I misinterpretaing your statement? Thanks for your advise here, I'm guessing that his is not a bug at all, just a misuse of your API so feel free to close it ;)
I'll leave this open to record that we should be specifying OperationCanceledException in our API for methods that can throw it (generally methods that take an IProgressMonitor, but don't return an IStatus).
Fixed in HEAD.
.
