Frank Schönheit - Sun Microsystems Germany wrote: >> In >> every case where you throw an exception you should be OK with preventing >> futher execution of the code of the caller. > > In this case, we're talking about insertion into a container, which > already (potentially) throws exceptions. So the caller needs to already > handle those.
Ah, I see. This makes a difference: this API isn't useable in Basic anyway (or only at the cost of a script abortion in case of errors) so adding the new exception doesn't create an additional problem. Sounds reasonable then. >> We did this mistake in our css.util.XCloseable interface and now we had >> to add a locking service that just removes the complexity of the >> exception process for those who don't want to or can't deal with it. > > Can you elaborate on this, for me to better understand the problems of > this approach? After discovering that the XCloseable API is not usable in Basic and also a bit "expensive" in other languages we tried to make it easier for the most common use case: someone wants to prevent an object (e.g. a document) from becoming closed for some time until he's done with it and then either stays out of the closing negotiations or closes the object (because he vetoed a close() call with parameter "true"). A simple way to implement this is to create a helper object (a UNO service) that registers as a CloseListener at the closeable object (document) and always throws a CloseVetoExeception as long as it is there, so the basic code can create the object and once it wants to release the document get rid of the helper object that automatically will deregister and disappear. We also extended this concept by allowing to register a callback at the helper object that will be called before a veto exception is thrown. This will prevent that the helper object throws VetoExceptions forever just because it was created from an external process and OOo has lost its connection to it. In this case the callback will end in BridgeDisposedException that will be caught and taken as a sign that vetoing is no longer needed. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
