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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
