Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 312284

Summary: [repository] getting index file is guarded by a throwable
Product: [Eclipse Project] Equinox Reporter: Pascal Rapicault <pascal>
Component: p2Assignee: Ian Bull <irbull>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 Flags: pascal: review+
dj.houghton: review+
Version: 3.6   
Target Milestone: 3.6 RC2   
Hardware: PC   
OS: All   
Whiteboard:
Attachments:
Description Flags
fix v.1 none

Description Pascal Rapicault CLA 2010-05-10 11:50:35 EDT
I came across the following code in the AbstractRepositoryManager and wonder why can't we simply check the transport error rather than catching Throwable.
			// get the search order from the server, if it's available
			ByteArrayOutputStream index = new ByteArrayOutputStream();
			LocationProperties locationProperties = null;
			try {
				getTransport().download(getIndexFile(location), index, monitor);
			} catch (Throwable e) {
				// If any exceptions are thrown, just ignore the index file
			}
Comment 1 Ian Bull CLA 2010-05-10 12:01:26 EDT
I did this so getting the index file would not cause any problems. I wanted to make the fetching of the index file as least disruptive as possible, and while I don't expect the transport to throw any exceptions, if it does, then we can consider the index file to be missing.
Comment 2 Ian Bull CLA 2010-05-10 15:33:02 EDT
Created attachment 167792 [details]
fix v.1

This removes the catch throwable, and refactors the code a bit.  If the download failes (with an exception) it will be propagated up.  If it fails with a status, then we just ignore the index file.
Comment 3 Ian Bull CLA 2010-05-11 00:05:34 EDT
Pascal, feel free to review this and mark it RC1. If not, we can put it in 3.7.
Comment 4 Ian Bull CLA 2010-05-17 23:21:33 EDT
Pascal,

This will fix the user cancel problem (since we won't eat the user cancelled exception). It would also be good to get this in before we fix bug 306816 as there will be considerable overlap.
Comment 5 Pascal Rapicault CLA 2010-05-18 14:44:20 EDT
Ian you can start looking at bug #306816 assuming this patch will be in.
Comment 6 Ian Bull CLA 2010-05-18 14:52:57 EDT
(In reply to comment #5)
> Ian you can start looking at bug #306816 assuming this patch will be in.

I already put a patch on bug #306816.  The fix is just to treat files differently.
Comment 7 Pascal Rapicault CLA 2010-05-18 16:01:58 EDT
Patch released.