| Summary: | [Undo] TriggeredOperations should close open operation on RuntimeExceptions | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> |
| Component: | UI | Assignee: | Susan McCourt <susan> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.2 | ||
| Target Milestone: | 3.2 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 134227 | ||
|
Description
Dani Megert
Susan, I think I got this one right (at least you're active on this class...) let me know if you wnat it reassigned... Marking for RC1. The problem is in TriggeredOperations. It catches ExecutionException and cleans up the open operation, but does not catch runtime exceptions. In the platform text case, an AssertionFailedException interrupted the undo, and the TriggeredOperation did not catch this. During discussions in bug #87675, we noted that the operation history should not attempt to fix or hide the illegal state, but to throw the exception. It's up to the clients to do the right thing. In this case, the offending client is TriggeredOperations. The undo, redo, and execute methods need to close the operation on runtime exceptions. Fixed >20060410. TriggeredOperations now catches RuntimeException in addition to ExecutionException. I could not reproduce the problem reported in bug #134227 (I think it has been worked around on the text side), but I was able to write a test case, OperationsAPITest.testExceptionDuringOpenOperation(), that demonstrates the history being left in an illegal state by a runtime exception during the undo of a TriggeredOperations. verified on I20060413-0010. Test case passed. |