Hi Mathias,
>>This to sounds like a limitation of the concrete UNO language binding
>>for Basic, not like a limitation of the concept.
>
> Of course it's a limitation of the language binding but IMHO we
> shouldn't design concepts from that we know that they don't work in at
> least one important language binding.
Sure. Just wanted to point out that if the impossibility to throw in
Basic *were* the only problem, than implementing this possibility would
have been the better alternative, IMO.
> Even if you don't want to create a listener and you just want to call
> "close(true)" in Basic to make sure that the document will get closed
> *in case there is no other interested party anymore* you might get an
> exception that will stop your program though there is no real reason for
> it.
That's a pretty good point :)
So the real problem here is that an exception was used to indicate a
perfectly valid situation: My script wants to close, somebody else takes
ownership, and *indicates this with a veto exception* - the latter is
the design flaw here.
(in real, what the script tries to do is not "close", but "deliver
ownership to somebody else who's interested in, if there's nobody, then
close")
Note however that this doesn't mean that VetoExceptions are a design
flaw *in general*. As described for my other scenario: If the veto
really indicates a failure of what I wanted to do ("insert an element
into a container"), then it's IMO appropriate to throw this veto as
exception.
Anyway. XContainerApproveListener now uses XVeto as return value, since
there's still the valid point that exceptions are expensive in quite a
few languages .... (then why did we introduce them in UNO? SCNR :)
Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
