Re: Attempt for an UNO Undo API

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