Hi Stephan,
> - Normal return; the underlying data model is in a state where the
> respective changes are indeed undone.
>
> - Exception "failed for some reason, undo call completely rolled back",
> i. e. the underlying data model is in the state it was in before the
> call to undo. It would probably be useful (if only for debugging) to
> transport the "for some reason" in the exception (as an any containing
> an exception).
Yes, already thought about adding some "TargetException" or so to the
UndoFailedException. Decided against it, since I was not sure whether it
has a real benefit. However "for debugging" is a benefit :), so I'll add it.
> - Exception "failed for some reason, but not rolled back", i. e. the
> underlying data model is in some valid state, but it is potentially
> neither the state before the call to undo, nor the state of a successful
> undo. Again, it would probably be useful to transport the "for some
> reason."
I don't think distinguishing those two cases ("undo call rolled back
completely" and "undo partially done") makes too much sense. In any
case, the only reasonable option for the caller is to clear the
respective stack, since it cannot know whether invoking the action will
succeed next time (temporary vs. permanent failures).
Also, not having the distinction simplifies the implementation of the
actions, making them less error-prone.
Thanks & Ciao
Frank
--
ORACLE
Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com
Oracle Office Productivity: http://www.oracle.com/office
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
