Hi Stephan, >> 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. > 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". Thanks & Ciao Frank --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
