Community
Participate
Working Groups
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
Nice to do but not a committed item on the 2.0 plan. Changing resolution to LATER.
Changing severity to enhancement. Re-opening bug for consideration.
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.
