Hi Stephan, >> 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 ... Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
