Re: Attempt for an UNO Undo API

On 10/25/10 16:02, Frank Schönheit wrote:
>>> 1. whether XUndoManager.undo/redo, when invoked while an Undo context
>>>      is open, should
>>>      a. throw
>>>      b. silently and implicitly close all open contexts
>>>      c. ignore the call
>>>      d. other?
>>> 2. whether XUndoAction.undo/redo should be allowed to raise exceptions
>>>      (except the always-possible RuntimeException)?
>>> 3. how to deal with XUndoAction.undo/redo throwing an exception?
>>>      a. silence the error?
>>>      b. propagate the error to the caller of XUndoManager.undo/redo
>>>      c. clear the respective stack, since obviously the top action cannot
>>>         be invoked, thus the other actions, which may depend on the top
>>>         action, also can't
>>>      d. both b. and c.
>>>
>>> I tend to 1a., 2-yes, and 3d., but would appreciate any opinion on this.
>>
>> IIUC, 1a means throwing for a temporary failure, so 3c appears to be too
>> aggressive?
>
> Ah, interesting. No, I didn't think about temporary failures - e.g. ones
> whose cause may have vanished when undo is called the next time. Do you
> think it might make sense to have this distinction? "permanent" vs.
> "temporary" failures? In this case 3c is too aggressive, indeed.

Sorry, I had mixed things up.  Forget my comment.

>> Also, question 2 should rather be "what exceptions exactly should be
>> raised," right?
>
> Well, yes. Having seen too many APIs where the specified exceptions are
> too ... limited, I thought of allowing a plain css.uno.Exception. Your
> question seems to imply you would argue for a more specific error :)
>
> 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.  A UNO method

   T m(...) raises E1, ..., En

has n+2 ways to return: return normally, return by throwing E1, ..., 
return by throwing En, or return by throwing a runtime exception. For 
the first n+1 cases, it is specified in what a state the program is 
after returning from the method (so program code can meaningfully react 
to the specific case).  For the last case (throwing a runtime 
exception), the state is less specified, and it typically does not make 
sense to react in a targeted manner (other than to clean up and 
propagate the error further out).

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.

- E' is not of general interest to callers of undo, they would not react 
to it in specific ways, anyway.  Then use a runtime exception 
(potentially WrappedTargetRuntimeException) to propagate it from undo.

-Stephan