On 10/26/10 11:48, Frank Schönheit wrote:
I think any kind of error can happen inside an undo implementation for a
single action, so I can't think of any reasonable limitation here. A
WrappedTargetException might be appropriate, but then again, this is
just an euphemism for "anything can happen".
I see it differently.
...
If an initial undo method has been specified to raise n different
exceptions, and it is later found out that an additional exception E'
would be needed, there are two choices:
- E' is of general interest to callers of undo, they would want to react
to it in specific ways. This is similar to detecting that a method
misses a parameter: Extend the method (add the raises-specification to
the existing method definition, rendering it incompatibly, or add a new
interface with the fixed method), fix up the implementation, fix up the
call sites.
Given the hurdles imposed on incompatible API changes, I dare to go this
way - experience shows rarely anybody ever goes through this pain,
"only" for having a clean API. Usually one ends up with throwing, guess,
WrappedTargetRuntimeExceptions (I thus consider the mere existence of
this class a bad hack. Well, a way-too-easy door opener for bad hacks,
that is.).
For the moment, I declared an UndoFailedException, derived from
css.uno.Exception, and let undo/redo throw it. Still an euphemism for
"anything can go wrong", though, so I am not that happy with it ...
For undo, I see three interesting return cases:
- 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).
- 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."
Everything else (failed, and the underlying data model is in some
potentially invalid state) calls for a runtime exception.
So, the UndoFailedException might indeed be the way to go here.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
