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

Bug 3023

Summary: [resources] Should check progress monitor cancelation more (1GD3KX2)
Product: [Eclipse Project] Platform Reporter: DJ Houghton <dj.houghton>
Component: ResourcesAssignee: Platform-Resources-Inbox <platform-resources-inbox>
Status: RESOLVED INVALID QA Contact:
Severity: enhancement    
Priority: P3 Keywords: helpwanted
Version: 2.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description DJ Houghton CLA 2001-10-10 22:48:02 EDT 
Our code should be checking the progress monitor more often to see
	whether or not it has been canceled. Current code pattern to do this
	is via Policy.checkCanceled(IProgressMonitor). We need to 
	remember to catch OperationCanceledException in the code and
	behave appropriately (rollback, etc.) before re-throwing it.

NOTES:

JM (06/05/2001 11:41:32 AM)
	Yes.  This is very important. Especially doing checkCanceled on the 
	longer multioperations.  We should spec (at least internally) which methods
	do checkCanceled as this implies that we could get a runtime exception at 
	any time when calling such methods.
	
JM (5/18/2001 11:18:54 AM)
	Added to build.  Still need to check other operatoins.

RTP (6/4/01 1:23:20 PM)
	See also 1GE70X8: ITPUI:ALL - Delete ignores cancel

JM (05/06/2001 6:09:14 PM)
	Uneasy about adding cancel paths to the code at this point.
	seek confirmation

JM (05/06/2001 7:13:02 PM)
	Defer
Comment 1 DJ Houghton CLA 2002-01-08 14:16:04 EST 
Nice to do but not a committed item on the 2.0 plan.
Changing resolution to LATER.
Comment 2 DJ Houghton CLA 2002-09-10 10:35:24 EDT 
Changing severity to enhancement.
Re-opening bug for consideration.
Comment 3 John Arthorne CLA 2004-11-24 14:37:37 EST 
Closing this old bug.  Better to have specific bugs for particular API methods
that don't have good cancelation responsiveness (of which we have a few). 
Overall, we're not bad for most methods.